Der schöne Günther

Just use a VM. Problem with an update, something not working as it should? Just roll back. Takes just a couple of seconds and you can be sure everything is in a state that is working fine.

I just noticed that if the breakpoint has a condition, the pass count reflects the number of times the condition was true. That's actually pretty nice. Now if only one line could have multiple breakpoints with different conditions... 😇 PS: Fun fact: If you kill the process with [Ctrl]+[F2] rather than letting it terminate gracefully, the IDE will still show the last pass count for a breakpoint.

Cannot reproduce: unit Unit1; interface type MyAttributeOne = class(TCustomAttribute); [MyAttributeOne] TMyObject = class(TObject); implementation end. program Project1; uses System.SysUtils, System.Rtti, Unit1 in 'Unit1.pas'; var ctx: TRttiContext; rttiType: TRttiType; attribute: TCustomAttribute; begin ctx := TRttiContext.Create(); rttiType := ctx.GetType( TypeInfo(TMyObject) ); for attribute in rttiType.GetAttributes() do if(attribute is MyAttributeOne) then WriteLn('It is MyAttributeOne!') else WriteLn('It is something else'); end. will output It is MyAttributeOne!

It may sound irritating, but I don't use ORMs at all. Maybe that's because we usually don't have many things stuffed into relational databases, or maybe because this old article left a lasting impression: Object-Relational Mapping is the Vietnam of Computer Science (codinghorror.com). I have no proof, but that for the few times, it was more time-efficient to do it by hand than include a massive ORM library and learn how to use it properly.

To be honest, I have never heard of that, let alone experienced it myself. It is still working fine, at least for the parts where have not migrated to the (fantastic!) EdgeBrowser yet.

Function arguments are always evaluated, then passed into the function. This "IfThen" (which I have never seen before), is just a regular function. The compiler has no knowledge that there is no need to evaluate the other arguments if the first one results to False.

The Command Design Pattern (sourcemaking.com) is generally used for undo/redo operations. Regarding databases: Not sure if you're looking for undo/redo or just transactions. Maybe this is relevant to you: Managing Transactions (FireDAC) - RAD Studio (embarcadero.com)

This is exactly what the MultiPaste tool is for. You can find it in Delphi at Edit -> MultiPaste. Using the MultiPaste Tool - RAD Studio (embarcadero.com) (I think the picture they posted is incorrect, as it is not realated to MultiPaste at all)

I am running "Delphi 11 and C++ Builder 11 Update 1" which is, I believe, the most current version. However, the integrated Sqlite library the IDE makes use of (FireDAC), is considerably older. I'd like to update it, as the query editor doesn't even understand some of our queries anymore. Double-clicking on a TFDConnection, then navigating to Info reveals the following: ================================ Client info ================================ Loading driver sQLite ... DLL = <sqlite3_x86.obj statically linked> Client version = 3.31.1 I found a sqlite3.dll in C:\Program Files (x86)\Embarcadero\Studio\22.0\bin and replaced it with the most current version, downloaded from the SQLite Download Page. However, that changed nothing. I have no idea how to proceed. I find dozens of guides how to manage the dll your own application will pick at runtime. But I am looking for the IDE, bds.exe. How to update sqlite?

I would have considered going to quality.embarcadero.com - But it's been down again since yesterday 😉

Yes, fancy things like these were exactly why I updated 😊 🎉 It already works fine in my application by setting the driver link settings to "dynamic" (as you mentioned). I just wish the IDE would also be capable of that. Instead of being tied to an outdated version of sqlite that is baked into it. There really is no reason to do that, it's a very strange design decision.

Thank you for the swift reply, that's what I feared. I have no clue why they did it that way. Every freeware tool I know has the sqlite.dll in a separate library, so that it can be updated later, even when the tool itself is no longer supported.

Yes, __fastcall has zero effect on x64 and ARM, compilers will usually just ignore it. It seems ctors/dtors are a special case when it comes to calling conventions. See [RSP-30762] [bcc32c]: fastcall calling convention ignored on constructor/destructor - Embarcadero Technologies [RSP-23671] Unexpected compiler error - Embarcadero Technologies [RSP-33071] [bcc32c error] virtual function '~XXX' has different calling convention attributes ('void ()') than the function it overrides (which has calling convention 'void () __attribute__((fastcall))') : overridden virtual function is here - Embarcadero Technologies From what I gathered, Embarcadero maintained their own patch queue of modifications for clang so that calling conventions were handled also for constructors/destructors but appearantly, they are struggling to keep up with clang development.

That is not a good idea, even with something like 32 × 32 pixels. You should always have an alpha layer, where pixels are neither entirely black or "not there", but something in between. So that it doesn't matter which background they're on: Here it is getting more obvious: In our VCL applications, we're using png files. Theyre small, lossless and support alpha channel. If you can, you could even consider vector graphics like SVG. That way, you won't even have to worry about supplying different resolutions for different displays.

Not sure about hooks, but it looks the spooler API has what you need DocumentEvent function (Winspool.h) - Win32 apps | Microsoft Docs FindFirstPrinterChangeNotification function (Winspool.h) - Win32 apps | Microsoft Docs

I stopped using C++ Builder because of the truly abysmal exception handling with Clang. The leaks were the least of my concern. According to [RSP-13173] C++ compiler exception handling is completely broken - Embarcadero Technologies, it should have been fixed, and they even had a blog post how it should have been improved with 10.4.2: (Source) Sad to see it's still not properly fixed. They have been having the LLVM backend for C++ for what now... ten years?

I am not familiar with the GExperts formatter, never used it before. Is it true that it is hard-wired to always use spaces for indentation? I only found an option to set "Spaces per Indent". Many thanks in advance.

If a TObjectList<T> has OwnsObjects = True, it will free the contained objects when the list itself is freed. If no one ever frees the list, it will stay in memory, and all its contained objects. You say you produce a new list. If no one else keeps a reference to the old list anymore, it should be freed. Even better, in my opinion, would be not creating new lists all the time, but that you change your helper object so that you pass your already existing list, and it will add the new object to that list, instead of creating its own. This way, you don't have to deal with creating and freeing lists, you just have one single list of the entire lifetime of your outer object.

We also use GetLastInputInfo() for exactly that (revoking any special permissions on a kiosk system if there has been no input for a few minutes). It's been working fine since we added it in 2016. Keep in mind that the tick count returned by GetLastInputInfo() is just a DWORD - Meaning it will roll over after 49.7 days. Our users were not happy when they were immediately logged out again after the system had been running for more than 50 days 😐

Have you checked and run the example programs in the Samples subdirectory? For example, in Samples/Component Demo, it is a complete application with a EidReader component on the form. This component has several events like OnCardInserted. My suggestion is you just try out the samples, they seem simple enough.

Oh, in that case, absolutely. Guess I should watch it.

What did I miss? What I understand is that It is not part of the language, it is just a regular method from the standard library Earlier versions did have an untyped parameter and let you pass in things that were not descendants of TObject If that is all, how can you even have an opinion on that? What is there to talk about? Can somebody get me up to date with just one or two sentences? Many thanks.

That they cannot be passed as var or out was more a comparison to simple fields, I should have made that clearer. Meaning: If you don't need getter/setters, I fail to see why you would ever go with properties at all.

In my absolutely personal opinion, never bother with properties at all. There is no real use for them. They have a lot of other disadvantages - You can't pass them as var or out parameters, Code completion will not tell you if a property is writeable or not. Many other languages are perfectly fine with no properties at all. I can think of C# properties, but they are capable of so much more. In Delphi, a getter/setter makes it immediately clear if a value can be read or written, makes it obvious that there could be side effects as it's not just a regular variable, and can be stored in a function pointer. Also, you can make the setter protected and only allow yourself and your subclasses or another interface to change the value. None of this is possible with properties. In my opinion, they just get in the way and require even more typing as Delphi is already incredibly verbose.