Sherlock

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

Have you looked into iOSApi.CoreMotion? It does sound like a good place to start.

OT: BPL hell. I build monolithic applications. copy the exe anywhere and run it. Never even considered using dll or bpl "technology". All I ever see is drawbacks to this kind of software development.

True for more than one reason.

Oh! OK, sure, that'll work just fine. 👍 But the underlying point is if a manufacturer chooses to implement a feature, he should fix the bugs.

@Pat FoleySorry, I don't get it

While it is a nice thing to be able to use your own charset during development, it is something I would never encourage or do myself. You will never be able to have someone outside your language read and understand your code. That said, this is a bug and you should just report it in the Quality Portal: https://quality.embarcadero.com/secure/Dashboard.jspa

11.2 will now need a totally reworked Wuppdi Welcome page. Which is a good thing because "no more Internet Explorer"

Just call Invalidate for the entire form. Or (if you really have to) call InvalidateRect for the rectangle of your label. Note that InvalidateRect is still a method of your form, not of the label. But you will have to use some form of threading to get that application responsive anyway...

According to the installation notes Delphi 11.2 can only run on Windows 10....nicely done.

Out of curiosity: How would binaries created with this fare on a Ryzen processor? Are Intel and AMD still 100% compatible? AFAIK Ryzen had problems on Win11 well into this summer, but that was because of TPM.

No, not at all. There are plenty of FMX Android Apps. Keep in mind however, you will need to update your Delphi as soon as a new version is released to keep up with requirements from new Android versions.

Firstly, that information is roughly four years old (which is ancient history in our line of work) and secondly no Delphi developer would have an Android App, which seems not to be the case. Sherlock

Sorry, but @Lainkes clearly stated, the data is not entered by the user. So no focus on fixing user errors needed here. Remains the unanswered question, about the origin of the date. How did this possibly erroneous value get into the Edit in the first place? Is it from a database? Or maybe some text file? Retrieved from a web site? All of which have appropriate methods to ensure correct data types and values. Fixing the issue on the GUI is way to late.