Sherlock

Check out AddFontResourceEx and RemoveFontResourceEx from the Windows API. Note that while the font is installed, it may be used by any other program in your system unless you load it FR_PRIVATE.

And then there's always: https://docwiki.embarcadero.com/Libraries/Alexandria/en/FMX

So, I have no Idea, what the issue really is, it is not FileExists. At least the way I try to reproduce missing privileges no exception is raised... so I retract that statement as bogus. Sorry for the fuss.

Just happened to me in at least 10.4.2 may even be so in 11.2. But maybe it is something else, will try to put together a small demo, time permitting.

Design time DB connections have been a pain for me in the past in several ways. Normally now I have no connection, and enable only when needed (which is rarely the case anyhow). Result is way less problems.

Just for completeness sake it should be noted, that FileExists will raise an exception, if the current user has insufficient rights to read the file. Turns out, that is completely false. Sorry about that.

I see that F is indeed checked further up. I only considered the last quoted portion of code. As for the "tutorial" it is quite tedious to follow. I personally hate video tutorials, because they are always to slow when it does not matter and to fast when it does. A readable tutorial is worth so much more than that. Anyway... I recreated the project as stated in the video,I even copied your code, and it works without errors. You must have done something different along the line...especially since your screenshot somewhat differs from the video.

Well, don't typecast without checking if the type fits. You need to check if F really is a TLayout and if child 0 really is a TLine. Something like: if F is TLayout then if TLayout(F).Children[0] is TLine then L:=TLine(TLayout(F).Children[0]); On the other hand you should only type cast when necessary. TFMXObject has a perfectly fine Children property no need to cast F into a TLayout. Check your entire code for these things and you should have eliminated one cause for the AV.

I admit it has been 10+ years since I looked into translation tools, but dxgettext was the least Delphi like with an inability to use resourcestrings. Multilizer and later on Sisulizer have been the tools of choice for me ever since. But I must admit I have not been needing localization tool in the past couple of years so my bias is very sure to be outdated.

Which line throws the AV?

It's called a data module. And you can search its dfm file like any other Delphi dfm...if it is not binary, which should be default.

Not a blog, but even better (IMHO): https://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre

Well I am just glad, that my applications seem to be barely more complex than "Hello World" because I really have none of these issues. But then again I use no inline variables, bpl, dll, 3rd party frameworks or language enhancements or any other new agey stuff I'm not able to wrap my head around anyway. Just plain old Delphi plus generics. And that works really good.

The question is, what happens to myParentNode before the if statement. How is it initialized/filled?

Do you mean, these sources are located in the folders of your XE5 installation?

Nonono, of course not. I just wanted to weaken the "it's just another tool in the box" argument.

There should actually be a refactoring tool to "de-with" a portion of code. That would be really cool. And something else is in the toolbox you would not dream to use: Goto

I wonder why some obvious things keep breaking unnoticed...

That is basic stuff, perhaps you should consider a Delphi course or reading a book.

This is at design time, does the issue persist at run time?

Just to be sure: The patch does not fix the path issue automatically, correct? Because after installing the patch, the path was fixed (or never has been broken).

That is easy and the solution comes in two parts: 1. Create an Issue on the quality portal. And b) Copy the source into your projects folder or any other folder where you would keep reusable units. Then fix the issue and add said folder to your search path to use the modified unit in your project.

Sorry, turns you do have to be careful when you copy & paste, edit and post code all willy-nilly. That "Message" is just the parameter of the message handler so in this case the abbreviated "msg".

Well, OnCloseQuery is simply not enough. You need to answer the OSes "Will shut down now" Message with a "Wait for me" and clear that "Wait for me" after you are done all the while keeping your main thread responsive to more OS messages that will come because Windows may not just take your word that you'll say "carry on" once you are ready, it will check on you... So what it boils down to is the following (if your application does not take longer than 30 seconds to do what needs to be done your golden, otherwise you'll need to be threading): type TForm1 = class(TForm) procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean); private procedure WMQueryEndSession(var Msg: TMessage); message WM_QUERYENDSESSION; procedure WMEndsession(var Msg: TMessage); message WM_ENDSESSION; public { Public-Deklarationen } end; var Form1: TForm1; implementation {$R *.dfm} var _ShutdownBlockReasonCreate: function(WindowHandle: HWND; Reason: LPCWSTR): UINT; stdcall; _ShutdownBlockReasonDestroy: procedure(WindowHandle: HWND); stdcall; function ShutdownBlockReasonCreate(WindowHandle: HWND; Reason: LPCWSTR): UINT; var UserLib: THandle; begin if @_ShutdownBlockReasonCreate = nil then begin UserLib := GetModuleHandle(Windows.User32); if UserLib <> 0 then @_ShutdownBlockReasonCreate := GetProcAddress(UserLib, 'ShutdownBlockReasonCreate'); end; if @_ShutdownBlockReasonCreate <> nil then Result := _ShutdownBlockReasonCreate(WindowHandle, Reason) else Result := 1; end; procedure ShutdownBlockReasonDestroy(WindowHandle: HWND); var UserLib: THandle; begin if @_ShutdownBlockReasonDestroy = nil then begin UserLib := GetModuleHandle(Windows.User32); if UserLib <> 0 then @_ShutdownBlockReasonDestroy := GetProcAddress(UserLib, 'ShutdownBlockReasonDestroy'); end; if @_ShutdownBlockReasonDestroy <> nil then _ShutdownBlockReasonDestroy(WindowHandle); end; { TForm1 } procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean); begin // Whatever needs to be done... end; procedure TForm1.WMEndsession(var Msg: TMessage); begin // Windows now informs you it will end your session // Free up your BlockReason ShutdownBlockReasonDestroy(Handle); end; procedure TForm1.WMQueryEndSession(var Msg: TMessage); const ENDSESSION_CLOSEAPP = $00000001; // lParam - WM_QUERYENDSESSION ENDSESSION_CRITICAL = $40000000; ENDSESSION_LOGOFF = $80000000; var CanClose: Boolean; begin // Windows asks if it may end your session, your response is // "No, and here's what you can tell the user why" if ((Message.Unused and ENDSESSION_CRITICAL) = 0) then begin if ShutdownBlockReasonCreate(Handle, 'Saving application data...') = 0 then begin SaveLog(SysErrorMessage(GetLastError)); //Assuming you have some kind of logging end; // Now do your thing i.e. call FormCloseQuery FormCloseQuery(Self, CanClose); If CanClose then Close; // Woohoo end else begin // Forcefully shutdown...no time to wait end; end; I have something like this in an application and it has worked for me since Win7. Not tested on Win11 yet though.

Nowadays power switches on PCs are no longer switches, they are buttons that send the users desire to power off (or on) to the ACPI. Only if the button is held longer than 5(?) seconds, it will really cut off the power. And @Ian Branch I suggest consulting your thread from two years ago: 😉