Leaderboard

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.

1. libmysql.dll must be in EXE folder, or in some folder which is in PATH, or in SysWOW64 for x86 and System for x64. 2. libmysql.dll must have the same bitness as EXE. Simple way to verify it: tdump libmysql.dll | find "CPU type" 3. libmysql.dll v 8 is not yet supported. Use version 5 or 6. Which one - almost not important. 4. Note, that libmysql.dll, depending on version, depends on MS C RTL.

defer your showmessage with a custom message

Another suggestion I offer is that when you must evaluate more than a few terms, it can be helpful to make use of local variables. This is especially true where each of your terms is itself lengthy, such as SomeObj.SomeMember.AProperty. Similarly, if several terms evaluate properties in a complex object, then rather than writing: if SomeObj.SomeMember.TermOne and SomeObj.SomeMember.TermTwo and SomeObj.SomeMember.TermThree then You might instead do: var obj: TMySubClass; begin obj := SomeObj.SomeMember; if obj.TermOne and obj.TermTwo and obj.TermThree then I also find that with many terms and long reference names, the odds of making errors in precedence increase rapidly. And the reason for that is that the mess in front of your eyes is approaching incomprehensibility. 😉

My roots were in hardware logic. Excess terms in hardware translates to using unnecessary parts, each with a measurable cost. Logic reduction is as important in software as in hardware. We don't see a hard cost for the unnecesary terms, but the cost is there, nonetheless. Look at the simplified form Lars presents. Not a big deal in small cases, but in complex chains of logic, failure to minimize becomes a maintenance issue; it impedes understanding.

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?

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.

There appears to be an ANDROID64 define (it's all over the Delphi source). Probably just not documented?

In that TPair record, TKey and TValue are Generic parameters, they belong to the TPair type itself. In C++, that TPair record type gets renamed to TPair__2 because of the Generic parameters. When the Delphi compiler generates a C++ .hpp file, it will declare a constructor inside that type. But since the type is renamed for C++, the HPPEMITs are being used to provide an implementation for that constructor using the new name. I have never seen the [HPPGEN] attribute before, though. It is not documented.

When I switched to Ubuntu for main OS, I put Ubuntu Mono in my Lazarus IDE and I like the result very much:

It doesn't matter - they all look terrible in the Delphi IDE on High DPI