Leaderboard

It is working in this case since TListboxStrings.Add (TListboxStrings is the TStrings descendant behind TListbox.Items) does indeed send a message (LB_ADDSTRING) to the control, and the control is visible on the form. But you should not rely on such implementation details when working in a background thread. Using Synchronize the pattern would be something like this: Synchronize( procedure begin Buffer.Add(LCurrentFile); end); where LCurrentfile is the local variable holding the filename to add to the listbox. The code goes inside your find loop.

You can't mix AllocateHwnd() with message dispatch methods, that is not how the system works. You need to handle the messages directly in the WndProc that you give to AllocateHwnd().

I'll be happy to sell you a copy.

And in professional that version of FireDAC can't connect to a server. It can only make local connections. With IBX you can make connections to a server.

Nope, you are wrong. There's a window behind that TStrings.

My first impression after opening the document: that's impressive, looks like the author spent a lot of time on it.

If you're using ProcessWindowMessage as the WndProc you declared with AllocateHwnd then it's no surprise that ProcessWindowMessage are seeing all messages. The message directive is used to build a message dispatch table but that table is only used if the messages are process via the Dispatch method. You could call Dispatch within your WndProc and have the message routed via the dispatch table (to another method) but there's really no reason for that extra indirection in this case. Just filter directly within ProcessWindowMessage.

I see a few problems with your code. In general you cannot access UI controls from a background thread, but you pass ListBoxPrograms.Items as the Buffer parameter to the thread's constructor. This can work if the Add method of ListBoxPrograms.Items is implemented by sending a message to the listbox control, since the OS makes sure a message is delivered in the thread that created the control's window handle. On the other hand the VCL creates a control handle on an as needed basis, and if the ListBoxPrograms.Handle has not been created yet when the thread tries to add the first item the handle would be created in the background thread context, which would not work since this thread has no message loop. So: Always access UI controls only in a Synchronized or Queued method! You did not show code for the ListFilesDir method, so perhaps you are doing that already. The second point to investigate is how to safely interrupt the thread's work if it has to be killed before it has completed its work. The TThread Destructor calls Terminate and then waits for the thread to die gracefully (by leaving the Ececute method). For this to work as expected the thread's work loop has to check the Terminated property on each round and exit directly if it is true. Again this is something you would do in ListFilesDir. Then there is the question of error handling in the thread's work loop. The usual pattern is to wrap the whole body of the Execute method in a try except block and either pass a trapped exception to the main thread for reporting to the user via a Synchronized method (not a queued one!), or use the Windows.MessageBox function to report it directly. That API is thread-safe, while the VCL.Dialogs methods are not.

We are glad to announce that New Multi-platform FM Style "Mirage Light" just released: https://www.delphistyles.com/fmx/MirageLight.html New style has specific of Windows 11 and macOS Monterey UI!

A wiki wouldn't require a coordinator once it's set up but it would still need somebody to rule in case of conflicts and since people doesn't agree on style (which is why a style guide is needed in the first place) I don't see a happy outcome of that.

I happen to have downloaded a copy right after publishing. Here it is... Object_Pascal_Style_Guide_-_Developers_Guide.pdf

Hi. I'm sorry we could not (or did not) update earlier. The delay is not to do with high DPI. The plugins should work fine with high DPI 🙂 The delay has been integrating and changing our build system. They were integrated as third party projects and we have been bringing them into our normal system (they'll still be shipped in GetIt as installable plugins for the foreseeable future.) We haven't wanted to promise a date, but (without promising) I would expect them to be available with 11.1.