Sherlock

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: 😉

Looks peculiar enough to say: I don't understand half of what is written there. Is the compiler not deterministic anymore?

No need to be sorry, we've all been there. Cheers

No screenshot in the docs, but no mention of the possibility (or need) to edit the path of an installed package either. So I guess you are just tired... grab a beer and get some shut eye.

I wonder where you might want those dots to show up? After a package is installed, editing its path seems rather pointless. And that dialog looks just the same on my system. So I thought maybe you have some strange dpi settings, that confuse the dialog. But there seems to be everything OK with it. I'm checking for the official docs to see if they have a screenshot.

Could you post a screenshot please? And what are your DPI settings?

There is a Wiki for DUnitX, which also explains installation: https://github.com/VSoftTechnologies/DUnitX/wiki/Wizard-Installation