Leaderboard

There are a few things that every single one of our internal programs should do: Every dialog should be sizeable if it makes any sense at all. Delphi makes that easy with the Align and Anchor properties. Ask yourself the following questions. If you answer any of them with Yes, ... https://blog.dummzeuch.de/2019/04/03/things-that-every-desktop-program-should-do/

Well, then you went down the wrong rabbit hole, and you need to start climbing your way out of it. Such as? You really need to stop using ProcessMessages(), and start using proper code designs. Even if you don't want to use timers/threads, there is always TThread.ForceQueue(), for instance. Anything that allows code flow to return to the main UI message loop naturally will be better than manually pumping the message queue artificially. Then file a bug report with Embarcadero. But don't litter your code with ProcessMessages() calls just to satisfy the framework. Find other alternatives. Stay away from ProcessMessages() whenever possible. That was true even in the old days of the VCL. More so now in the days of FMX on mobile.

This is definitely not the right way to write code. Avoid ProcessMessages() whenever possible. The example given can be replaced with a simple UI Timer instead, eg: ProgressBar1.Value : =0; ProgressBar1.Max := 100; Timer1.Enabled := True; ... procedure TForm1.Timer1Timer(Sender: TObject); begin ProgressBar1.Value := ProgressBar1.Value + 1; if ProgressBar1.Value >= ProgressBar1.Max then begin Timer1.Enabled := True; Exit; end; //... end; But, if your real project is using the ProgressBar to tracking status of actual tasks, those tasks should be done in the background, and updates to the UI synced with the main UI thread accordingly.

Hmm.. Who 'is Active'? I login nearly every day, read nearly every changed thread.. But, of course, I only answer, if I have something to write... And this is actualy nearly nothing... Are I am an active User (reading) or not, of course I write nearly nothing? 😉

Explanation from Marco why it does not work and they are not going to fix it: https://quality.embarcadero.com/browse/RSP-22888

Shameless self promotion: On StackOverflow somebody asked the question in the title and I answered it. And as you might have guessed, I am might proud of having had that idea. It might be interesting to know that this is how GExperts fixes some of the IDE bugs and enhances some forms: It creates a TComponent descendant which hooks some events of the form to implement the fixes or enhancements. And since it is added to the form, it automatically gests freed in the form’s destructor. https://blog.dummzeuch.de/2019/04/03/extend-the-event-onclick-of-all-menuitems-in-the-screen-to-execute-another-block-of-code/

Check, so the free tool can downshift to accommodate Delphi 🙂 http://wiki.freepascal.org/Helper_types#record_helper

https://quality.embarcadero.com/issues/?jql=text ~ "inline variable" and affectedVersion in ("10.3 Rio"%2C "10.3 Rio Release 1") and status not in (Resolved%2C Closed)

IDE tooling does not work properly and some of it completely stops, Also inline variables of a managed type are not always properly initialized. As much as I like this feature syntax wise - I would stay away from it for now 😞