Der schöne Günther

Thank you for your first hand insights into using a Windows ARM machine with Delphi. I stopped following the progress on WindowsOnARM a few years ago, so I am not up to date. Would you be willing to tell more about your daily usage, maybe in a separate thread? I'd be absolutely interested in typical day to day usage, battery runtimes, standby/wakeup times and where it could start to get tricky (old printer drivers, shell extensions, obscure software,...).

For me, the demo code bails out with an exception on SetWindowSize(..). For some reason, GetLargestConsoleWindowSize returns (240, 54) which then causes your function to raise an EArgumentOutOfRangeException. Which seems to be matching the .NET counterpart. So all is fine, and my computer is acting up. Weird.

I don't get a warning for the above code at all 🤷‍♂️

Neu bei DP registrieren klappt anscheinend nicht - Delphi-PRAXiS

Have you considered joining Embarcadero's marketing team?

Embarcadero has been having too many coals in the fire for years now. Instead of opening the next can of worms, they should be fixing basics like code completion. I remember being in the Microsoft Technology Adoption Program where you got Teams meetings with the developers behind WinUI and other Windows components, got shown not yet released roadmaps and got to ask questions. Back then, it was basically impossible to properly use WinUI outside of Microsoft's Visual Studio (not sure if it was WinUI2 or 3). At that time, they openly replied to me that they had no plans to change that. Except WebView2 has been usable for basically everybody from everywhere, and it's actually good. You can see it being used in a lot of software, not just Microsoft's own products. Just look at how much stuff Microsoft has abandoned in the last couple of years, how much of the "Universal Windows" approach has been dialled down or completely removed already. Not to mention that new GUI stuff has been highly dependant on the most current Windows version. WebView2 even works in Windows 7. I honestly was interested in WinUI around 2018 to 2020 or so, but it certainly never took off. I firmly believe it is not relevant anymore.

I am fully aware that Delphi's VCL interface library exclusively lives in the main thread. Everything VCL related must happen in the main thread. Do not access VCL elements, don't even create and destroy something like a VCL Bitmap or Canvas in a thread. Maybe you don't have to be that cautious, but that's what I remember. Yet, it still occasionally happens to us. An event that used to run in the main thread gets moved to a different thread. Sometimes, things might trigger something that might cause the UI to refresh something. I know that with perfect documentation and more attention this probably wouldn't happen. Yet, it does. My question: Are there any kind of "runtime checks" I can enable to "detect" -anything- from outside the main thread touches the VCL? My motivation is to easier "find" places where the UI layer is accidently accessed from outside of the main thread.

Thank you both, that is exactly what I was looking for. 😇 It's a pity the VCL itself uses it just this once but I am sure there were performance considerations. I think this brought me on the right track. I will probably use a TVirtualMethodInterceptor and use the OnBefore hook to watch for methods like ['Repaint', 'Update', 'SetBounds', 'DefaultHandler'] and then call CheckNonMainThreadUsage(). Not sure if it will be sufficient to just use one interceptor on a TForm or TFrame, or if I will need to have a VirtualMethodInterceptors for every kind of control (Buttons, Panels, ...). I will still need to figure that out. 🤔

Thank you, I am well aware of that. I am not directly accessing any GUI elements from threads. I am invoking events to which a VCL form or frame might be subscribed. Or background event handler might trigger something else that might then update the UI. Similar to like FastMM can throw an access violation at runtime when using memory after it has been freed, I am looking for something that might ~detect~ accessing the VCL in the context of a different thread.

I cannot contribute how to solve this, but having dealt mostly with Windows I also was surprised recently to find out about how differently this is handled on other platforms like macOS or Linux. Delphi's standard library was initially built for Windows and suggests you could easily enforce this on other platforms as well. For other languages like C++ or Rust, the standard library's file access mechanism don't even support any way "sharing" or "locking". Their default implementation is even "Don't lock anything, allow everything" which I found surprising. Maybe that was just my old Windows habits.

I only skimmed through the changelog, but what interests me most is the introduction of an entirely new debugger for Win64: https://docwiki.embarcadero.com/RADStudio/Athens/en/64-bit_IDE#Delphi_Debugger That -could- mean a huge step forward in writing & debugging Delphi code outside of the RAD Studio IDE.

Can you narrow it down further if the click you want to catch will be Still inside your own application Outside of your application, causing it to lose focus If mouse coordinates matter of you're just interested that a click happened

Not a Delphi library, just a technical article, but still an interesting read, if you have some time: Fast columnar JSON decoding with arrow-rs | Arroyo

function TWinControlHelper.CreateBitmap(): TBitmap; var DC: HDC; begin DC := GetWindowDC(Handle); try Result := TBitmap.Create(); try Result.SetSize(Width, Height); BitBlt( Result.Canvas.Handle, 0, 0, Result.Width, Result.Height, DC, 0, 0, WinApi.Windows.SRCCOPY ); except Result.Destroy(); raise; end; finally ReleaseDC(Handle, DC); end; end; I use this... Limited to TWinControl decendants, though...

Must feel fantastic to finally have found the cause after three long weeks ( ͡° ͜ʖ ͡°)

I've had this with faulty drivers from garbage companies like Intel. Their resource usage is nowhere to be seen in Task Manager, over time, they clearly eat up more and more system resources until the system starts collapsing. Once again, stuff like this is clearly logged in Windows Event Viewer. It might provide additional info.

Haven't played around with it much yet. For my taste, turning it on or off via // pasfmt off is a bit to unobtrusive. I think it should stick a bit out more so you immediately see. Something like #[rustfmt::skip] somehow just catches your eye better. Maybe it could also be possible via {$DEFINE NO_FORMAT}? That would also give us syntax highlighting for these parts.

It is a shame your MAILCONFIGS contains an array of objects that just contain another object. Normally, you would use JsonPath for that, but Delphi's JsonPath support is very limited. See: Query JSON documents with JSONPath – grijjy blog System.JSON.TJSONObject.FindValue - RAD Studio API Documentation Quote: "These operators do not support special expressions, they only support actual values (object properties or array indexes)." I am afraid you will have to find the MAILCONFIGS node, and then iterate through it via code.

Consider the following code: program Project1; uses System.SysUtils; type TSubRange = 1..10; var subRange: TSubRange; begin subRange := Default(TSubRange); Assert(subRange = Low(TSubRange)); // subRange should be 1, but is 0 end. I was under the impression, that the default value of TSomeRange would be 1 and not 0, a value that can neither be set at compile time, nor at runtime. Documentation of System.Default - RAD Studio API Documentation is non-existent. Documentation about subrange types (Simple Types (Delphi) - RAD Studio) is a bit more helpful: In my case, it doesn't matter whether range checking at runtime is enabled or disabled. Default(TSubRange) seems to gloss over the definition of TSubRange, thinks "Hey, it's a byte" and just outputs 0. My question: - Is this valid behaviour? Has it changed? I am using Delphi 11.1 - Are there possibly any other caveats with subrange types? Maybe just not use them at all?

Did you forget a comma , before your "new_token": or is there really none?

To me, the form looks like is is that picture, with a transparent "blur" part in the middle. He/she has accomplished the shown part in pure VCL and is, understandably, proud of it. For myself, I am not going to try because I don't see the necessity to use the VCL for this, I would have made it in HTML/CSS. Still, I would be interested how this should ideally be done with good, old VCL.

I don't understand why there should be a constant recalculation of the "blur" effect. There is a background image, and a small portion of it in the middle has its background blurred. Isn't it always the same part of the image that is blurred? If the window becomes smaller, I would just crop the background image instead of re-scaling it.

Maybe just a TWebBrowser (preferably using the Edge/WebView2 engine) is an option?

I haven't really kept up with the latest Delphi versions. Is still still the same problem with the LSP from 2020, or is this something else?

Can't you just spin up a fresh VM with the same windows image and see if the problem persists?