Leaderboard

Sheesh ... for anybody else looking for this ... they renamed it to "Bonus KSVC" within GetIt.

later I'll publish a blog full of tips how to create highly scalable Indy, WebBroker, Soap, Firedac, Windows, Linux servers. A lot of utilities with Webbroker CRUD/REST helpers.

OK, found it: The problem was not the file name but the filter (Save as type): If I change it to *.* it works. Seems that Windows for whatever reason doesn't like the filter to contain a * at the end of the extension (in my case "*.SigBrightness*". If I switch to the filter "*.SigBrightness" (without the trailing *), Windows appends ".SigBrightness" to the file name, which I can then manually remove and save the file with the intended name. Now, how do I get Windows to show the selection I want but still let me save the file?

I guess you meant "Congratulations LLVM team!" 🙂

See workaround in https://quality.embarcadero.com/browse/RSP-22372.

But a program (such as an editor) needs to know if the file is UTF8 in the first place. Without a BOM, it must guess.

Not only that, but the code "if Somebool=True" has a little known pitfall. Every Delphi program interfaces with libraries written in C or C++ (such as the Windows API, all sorts of drivers etc) and in the C language, a bool is basically an INT. I have had a few cases where a function was supposed to return a boolean and in reality it returned some integer where 0 signalled FALSE. The code (if Somebool Then...) treats 0 as false and all other values as TRUE. That always works as intended. The code "If Somebool=True THEN ..." only treats 1 as TRUE and everything else as FALSE. CASE statements are affected, too. So the following code fails: var SomeBool:boolean; begin SomeBool:=Boolean(2); //Simulate a DLL returning a "wonky" boolean if (SomeBool=True) then ShowMessage('True'); CASE SomeBool of True: ShowMessage('True'); False:ShowMessage('False'); END; If Somebool then ShowMessage('Still it is true...'); end;

Getting rid of something can be a bit tricky when you need to maintain your code also with older versions. The basic idea is to introduce that new property with an empty default value matching the current behavior. This will keep the DFM clean and ParentFont functioning as before. These are the parts for a possible implementation: type TFontElement = (pfeCharset, pfeColor, pfeHeight, pfeName, pfeOrientation, pfePitch, pfeSize, pfeStyle, pfeQuality); TFontElements = set of TFontElement; The new property ParentFontElements would be initialized with an empty set, which would be omitted when writing the DFM. property ParentFontElements: TParentFontElements read FParentFontElements write SetParentFontElements default []; The implementation would not affect any rendering at all. It can be implemented completely inside TControl.CMParentFontChanged without any impact to any other place. procedure TControl.CMParentFontChanged(var Message: TCMParentFontChanged); begin if FParentFont then begin if Message.WParam <> 0 then SetFont(Message.Font) else SetFont(FParent.FFont); FParentFont := True; end else if FParent <> nil then begin { TODO : order might be relevant } if pfeCharset in ParentFontElements then Font.Charset := FParent.Font.Charset; if pfeColor in ParentFontElements then Font.Color := FParent.Font.Color; if pfeHeight in ParentFontElements then Font.Height := FParent.Font.Height; if pfeName in ParentFontElements then Font.Name := FParent.Font.Name; if pfeOrientation in ParentFontElements then Font.Orientation := FParent.Font.Orientation; if pfePitch in ParentFontElements then Font.Pitch := FParent.Font.Pitch; if pfeSize in ParentFontElements then Font.Size := FParent.Font.Size; if pfeStyle in ParentFontElements then Font.Style := FParent.Font.Style; if pfeQuality in ParentFontElements then Font.Quality := FParent.Font.Quality; end; end; The ParentFontElements are only used when ParentFont is False, which is automatically set when changing some Font properties. Thus setting ParentFontElements must internally set ParentFont to False and trigger CM_PARENTFONTCHANGED: procedure TControl.SetParentFontElements(const Value: TParentFontElements); begin if FParentFontElements <> Value then begin FParentFontElements := Value; FParentFont := False; if (FParent <> nil) and not (csReading in ComponentState) then Perform(CM_PARENTFONTCHANGED, 0, 0); end; end; Apart from some real world testing and adjusting this is probably all that is needed for an implementation.

It would have been trivial to solve if only you'd used the debugger. Make it your next mission to learn how to use the debugger.

Call it: .IsAdministrator and all is clear

My argument comes from the goal of reducing code clutter and sanitizing conditions to be easy to read. Original code if aUser.Username<>aDocument.Owner then begin // If user is not an administrator if aUser.Administrator=false then begin showmessage('You are not allowed to delete this document'); exit; end; end; A boolean is by definition either true or false. An if condition takes a boolean argument, and if the argument is true, the following statement is executed. I don't need to check if BoolVar = true or BoolVar = false - only checking BoolVar or not BoolVar is enough. To have readable code, avoiding negations is a good thing, hence I would probably write the above something like this if (aUser.Username = aDocument.Owner) or aUser.Administrator then begin // do the deletion end else ShowMessage('You are not allowed to delete this document'); Naturally, there is no single right way of doing conditions - but explicitly comparing a boolean variable to a boolean value is unnecessary.

It's simple. Why write if SomeBool = True then when you can write If SomeBool then It simply adds nothing.

That was exactly my thought when you made this comment: What was the error, and why was it hard to catch?

I have to admit that I cringe whenever I see a boolean compared to true or false.

Why is it so hard to reach the conclusion that aUser.Administrator is false? Instead of being helpless here, you can get help from us by providing a minimal reproduction. Easier still would be simply to debug your program. Have you done that?

Never compare to False or True. Instead write if someBool then Or if not someBool then That's not your problem though. Your problem is quite simple. It's the most obvious explanation. You are mistaken, in fact aUser.Administrator is false. It's that simple.

Yeah, modal dialogs and popup are deeply invasive. Find a different way to let the user know.

Then don't use ShowMessage() for that. It displays a modal TForm whose owner window (in Win32 API terms, not VCL terms) is the currently active TForm. An owned window is always on top of its owning window. For what you describe, use a normal TForm instead of ShowMessage(). Set its PopupParent property to the monitoring TForm that needs attention, and then show the popup TForm. This way, the popup Tform stays on top of only its monitoring TForm, but other TForms can appear on top of the popup TForm. Otherwise, change your UI to not use a popup TForm at all. Put a visible message inside the TForm that needs attention.