Leaderboard

Introducing "Uses Helper" - some little but incredibly helpful IDE plugin https://delphisorcery.blogspot.com/2021/03/introducing-delphi-uses-helper.html

This is bad idea. First, Application.ProcessMessages has some global side effects that can bite you in behind when you least expect them. Next, depending on the code, it is possible that some pieces still take too long to keep UI fully responsive. Using background threads for simple operations is not rocket science and at the end when you take all pros and cons it is not more complicated than using Application.ProcessMessages.

First, as we all know (I hope) if application cannot process messages, it becomes unresponsive and OS (and user) can kill it, because it may look like it is dead. Application.ProcessMessages pumps the message queue so the OS can see that application is still alive. There are few problems with that approach. Most obvious problem is that such code becomes re-entrant. That can cause some nasty side-effects depending on the code you are executing. But main issue is that you are still running slow operation in main thread, and no matter how much you are able to interrupt that execution with calls to Application.ProcessMessages, this will still slow down UI processing and application may respond to user input slowly. Also, this is not just the problem with reacting to input, but all the calls to Application.ProcessMessages will make that long operation running even longer. Next issue that is often overlooked is that some parts of the long running process may not always execute fast enough. Imagine connecting to some web service and retrieving some very small amount of data. In perfect conditions that may take blink of an eye, but if connection is bad for any reason, this operation can block the main thread for much longer. And Application.ProcessMessages will not help you with that. Also, for cross-platform development, this is more important because mobile devices will kill non responsive application much faster. On Android you cannot even freely perform network operations in the context of the main thread because OS will thow exception if you try. Also on android Application.ProcessMessages no longer works and can deadlock the application.

Please vote if you think the compiler could help us writing more robust code: https://quality.embarcadero.com/browse/RSP-33504

Run in the debugger. When it hangs, use Run | Program pause to pause execution. Look at the thread window, and double click the main thread since I guess that is the thread which is hung. Look at the call stack window which will tell you what the thread is doing that is not completing.

Oo yes, and if you giving status reports, you are the ProgressBar 😛

You know that annoying person constantly interrupting and asking you the status of some very busy task you are performing? That person is called Application.ProcessMessages

Nope. There is no method of TRttiContext that takes an object instance as input. FindType() takes in a class type as a string, and GetType() takes in a class type as a TClass or PTypeInfo.

Search for UNSAFE_CAST in QP and you'll find some issues that report all the bogus this produces - maybe after fixing those it might be somewhat usable. If that can avoid introducing yet a new warning type - I am all for that option.

My point is that from all things, happening during rescaling of a form, the most resource consuming are SetWindowPos calls, which are called from SetBounds, which are themselfs called from different places, including AlignControls. Drawing and especially async invalidation takes much less resources and time, imho. So, when we speak about form rescaling performance, we can denote it as O(n), where n - is mostly the number of SetWindowPos calls. To trace how many times SetWindowPos is actually called we can use WM_WINDOWPOSCHANGED event handlers on child controls. So, given very simple example with a single TPanel control, aligned with alClient on a form, I see three SetWindowPos on each dpi boundary cross: procedure TPanel.WMWindowPosChanged(var M: TWMWindowPosChanged); var cr: TRect; begin if (M.WindowPos.flags and SWP_NOSIZE) = 0 then begin Winapi.Windows.GetWindowRect(Handle, cr); OutputDebugString(PChar('WMWindowPosChanged: ' + cr.Width.ToString + ',' + cr.Height.ToString)); end; inherited; end; As seen from the events log the child panel is repositioned three times, and each time its size is set to different value: 638 * 380 510 * 304 640 * 382 So, in this particular case three times more work is done, than it actually required. Test project: dpi_test.zip PS: Looking more generally at this issue I have to conclude that layouting should be asynchronous. The concept of async layouting is a some kind of replacement of the global BeginUpdate/EndUpdate mentioned earlier. But, this will be too big and breaking change for VCL. And moreover, this is almost impossible for native Windows controls, such as TEdit, TListBox, etc.

Look at this: program Project20; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type TVectorD3 = record x, y, z: Double; end; TDirection = type TVectorD3; {$WARN UNSAFE_CAST ON} procedure Test; var V: TVectorD3; D: TDirection; begin V := default (TVectorD3); D := TDirection(V); end; begin try Test; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Will also produce a Warning. So if you enable UNSAFE_CAST there will be a lot of Warnings. And every place surround with a {$WARN UNSAFE_CAST OFF} is a bad Idea But I'm with Stefan here. A new Warning for Pointer Assignment would be fine.

I don't think you understand how the message queue works... How are messages supposed to arrive through Application.OnMessage if the message queue isn't being pumped? And if it is being pumped then your code is unnecessary because the messages are already being dispatched and processed. In short: Your code does nothing that isn't already being done.

I'm using this since you (pre-)released it back in the G+ era and I'm very grateful to you for creating it.

Since I seem to remember that you mentioned that you use GExperts: The description of your plugin sounds a lot like the Identifiers tab of the Uses Clause Manager. What functionality are you missing there that you went to the trouble to write your own?

The correct word is "Warror", sometimes also called "Errning" /s

Delphi Version: 10.4.2 MMX CodeExplorer: 15.0.34 build 2405 Windows: 10 Pro MMS Code Explorer 15.0.34 build 2405 does not save the width of the Member Search Bar. After restart the Delphi IDE it is narrow again. I have the ModelMaker Code Explorer docked to the left of the screen. After dragging the width of the Member Search Bar to the widh I like, everything is fine until I restart the Delphi IDE. Then the Member Search Bar is back to its default width (rather narror) again. It would be great if it saved the width I set and restore that width when I restart Delphi IDE.

Does anyone have any working example(s) on how to use OneSignal push notifications on iOS and Android?