Leaderboard

That is not entirely true. It does have side-effects if you are not careful. It allows pending messages from SendMessage...() from other threads to be processed (even though they don't go through the message queue themselves, they still require the receiving thread to perform message retrieval operations so they can be delivered). More importantly, it allows on-demand synthetic messages, like WM_TIMER, to be added to the queue (see Why is my message queue full of WM_TIMER messages?).

Back in Feb 2019, I blogged about the need for a Package Manager for Delphi. The blog post garnered lots of mostly useful feedback and encouragement, but until recently I could never find a solid block of time to work on it. Over the last few weeks I've been working hard to get it to an mvp stage. https://www.finalbuilder.com/resources/blogs/introducing-dpm-a-package-manager-for-delphi

I prefer overloaded methods, but only for cases of 1) the same set of parameters differing only in types (good example is IfThen) 2) several parameter sets (2-3) Dozens of methods significantly differing in param sets are usually hard to understand. Quite often I add an overload to utilize a default parameter of a type that Delphi doesn't allow to set in code, like record, object or array (like Error(Msg) and Error(MsgFmt, [values])).

As I said, you can call UnitName on every class declared in that unit. If the unit contains no suitable class declaration in the first place, you can always add one just for this purpose: type TClassInThisUnit = class; initialization LogThis(TClassInThisUnit.UnitName, SomeValue); end.

Install instructions are on Indy's website.

Cleaning the global library path from unwanted entries creeping in when installing a library with its own setup is a continuing task here. In my installations the global library path contains only what the Delphi installer writes to it. Every additional library path is added to the search path of the project that makes use of it. Option sets for each library not only simplifies this, but also give a visual clue in the project manager which libraries are used for the project. Also these paths are somehow included in the repository of this project. This way I can fire up a new build agent for Continua, install Delphi, FinalBuilder and whatever tools are needed - that's it. All my projects can be compiled on this machine. Gone are the days where hunting for missing libraries detected late in the build process - often when you are already in a hurry.

Without managing the global library path, a package manager would not work for me. I cannot think of any library we use that is not used by multiple Delphi projects; in some cases dozens. So no project search path is ever used or needed. Are you targeting just the type of development shop which builds only one or two huge applications? But don't pay too much attention to this comment, because as I have said before I am very happy using a Finalbuilder project as a DPM.

No. But while you're peeking at the message queue you might as well do something useful with it: procedure BusyBusyBusy; begin // Allow threads to synchronize CheckSynchronize; Msg.message := 0; try // Process cursor update messages for this window so cursor stays responsive while (PeekMessage(Msg, Handle, WM_SETCURSOR, WM_SETCURSOR, PM_REMOVE)) do begin if (Msg.message = WM_QUIT) then exit; DispatchMessage(Msg); end; // Process paint messages for all windows so UI can repaint itself while PeekMessage(Msg, 0, WM_PAINT, WM_PAINT, PM_REMOVE) or PeekMessage(Msg, 0, WM_ERASEBKGND, WM_ERASEBKGND, PM_REMOVE) or PeekMessage(Msg, 0, DXM_SKINS_POSTREDRAW, DXM_SKINS_POSTREDRAW, PM_REMOVE) or PeekMessage(Msg, 0, WM_PRINT, WM_PRINT, PM_REMOVE) or PeekMessage(Msg, 0, WM_PRINTCLIENT, WM_PRINTCLIENT, PM_REMOVE) do begin if (Msg.message = WM_QUIT) then exit; DispatchMessage(Msg); end; PeekMessage(Msg, 0, WM_NULL, WM_NULL, PM_NOREMOVE); // Avoid window ghosting due to unresponsiveness on Vista+ finally if (Msg.message = WM_QUIT) then begin PostQuitMessage(Msg.wParam); Application.Terminate; end; end; end; The above was snipped from existing code so might need to be tweaked slightly.