Remy Lebeau

The Parent will not be nil for top-level items, it will instead be pointing at the TMainMenu.Items property.

Again, appA MUST use startActivityForResult() in order to receive TMessageReceivedNotification with the result from appB.

I would suggest making the Action hold a pointer to the desired Form, and simply read the Form's current Name whenever needed. And if the Form's Name changes, then have the Form notify any Action that is pointing at it so they can use the new Name as needed. Easy to do if Actions register themselves with the Form so it can maintain a list of pointers to the Actions.

That code is performing floating-point division. And as Lejos mentioned, floating-point exceptions behave differently in Delphi 12 than they did in earlier versions. https://dalijap.blogspot.com/2023/09/coming-in-delphi-12-disabled-floating.html This is also documented by Embarcadero: https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms If you want to see a Call Stack at runtime, you have to display it yourself. You can catch the Exception (or use the TApplication(Events).OnException event) and then read the Exception.StackTrace property. However, this requires you to install a 3rd party exception logging library, such as MadExcept or EurekaLog, to populate the trace details. Embarcadero does not provide that functionality. In which case, you may as well use that library's own logging capabilities.

Not natively, no. But I'm sure a 3rd party one exists if you search around.

Are you using C++ or Delphi? Integer division or floating-point division? Can you provide an example that is not working for you?

You are not going to get a notification if you use startActivity(), you need to use startActivityForResult().

Even if you could lookup the database server's IP quickly, there is no guarantee that the database engine is actually running/responding, so you still have to wait for the full connection before you can do anything with the database, and still handle any failure that may occur. So, may as well just do that by itself, and deal with the slowness of reporting a failure (you should probably file a ticket about that).

Without having explicit knowledge of your home network setup, there is simply no way for your app to detect whether you are connected to your home network or not. You could try looking for a connected LAN adapter, but what if you are in a hotel that offers LAN access? You could try looking for a connected Wifi adapter, but most public networks are Wifi. You would need your Wifi's SSID to differentiate between a home Wifi and a public Wifi. I think you are making the issue harder then it needs to be. I would suggest taking out the guesswork completely and simply just provide two options in your program's configuration: - connect to a tcp hostname - local copy only And then make it easy to switch between the two configurations as needed. Perhaps wrap them in profiles and then switch the active profile when you leave home and then come home. Another option would be to just skip the local copy altogether and just always connect to your home database server even when you're on the road. Setup port forwarding on your home router and then register a static DynDNS hostname so you can easily find your router's WAN ip/port from public networks (and for added security, setup a VPN server on your home network and then connect to the VPN when on a public network). This way, you always have access to your database server and can connect to it via its IP or hostname on your private LAN. If you really want to go down this route, then you need to assign a unique static hostname to your database server, and then you can use gethostbyname() (or better, getaddrinfo()) to lookup that hostname whenever you connect to the database. No need to validate the IP prefix. If you connect to the database by hostname instead of by IP, then you don't even need to perform the lookup yourself, as most TCP libraries/database drivers will handle this task for you. But either way, if the hostname fails to resolve, then you are likely not connected to your home network. Done.

Ask the user. The OS only knows whether there is a network connection or not. It doesn't care where the network is located or what it's connected to. That's up to the hardware to deal with. No. And as far as sockets are concerned, there is no difference whatsoever whether you are connected to a wired LAN, or to a Wifi, or a cellular provider, etc. The socket API works the same way. The difference is in how the hardware routes the traffic. Likely because this is not what that API is intended for. What EXACTLY are you trying to accomplish in the first place?

Running a process as an (impersonated) admin user, and running a process in an elevated state, are two different things. Being an admin user does not imply automatic elevation, but an elevation prompt does require an admin user. In any case, perhaps have a look at the CreateProcessWithLogonElevatedW() and CreateProcessWithTokenElevatedW() functions provided in the Elevate DLL of this old CodeProject article: Vista UAC: The Definitive Guide (I think the site is down undergoing a redesign at the moment, though. Maybe you can find another copy of the DLL elsewhere).

You are catching the FORM'S paint event, not the BUTTON'S paint event. Every window receives its own painting messages (WM_PAINT, WM_DRAWITEM, etc). Your code can be simplified a little. If you use the button's WindowProc property, you won't need to call GetWindowLongPtr() directly (and even then, SetWindowSubclass() would have been a better choice). Also, since your DrawColoredTxt() function is completely erasing the button and drawing it yourself, there is no point in calling the default paint handler at all. Try this: ... procedure DrawColoredTxt(aBtn: TButton; aCaption: string); private FOriginalButtonProc: TWndMethod; procedure ButtonWndProc(var Message: TMessage); ... procedure TForm1.DrawColoredTxt(aBtn: TButton; aCaption: string); begin ... end; procedure TForm1.ButtonWndProc(var Message: TMessage); var PS: TPaintStruct; begin case Message.Msg of WM_PAINT: begin BeginPaint(Button2.Handle, PS); try FOriginalButtonProc(Message); DrawColoredTxt(Button2, 'Admin'); finally EndPaint(Button2.Handle, PS); end; end; // Forward all other messages to original handler else FOriginalButtonProc(Message); end; end; procedure TForm1.Button1Click(Sender: TObject); begin FOriginalButtonProc := Button2.WindowProc; Button2.WindowProc := ButtonWndProc; Button2.Repaint; end; procedure TForm1.Button3Click(Sender: TObject); begin if Assigned(FOriginalButtonProc) then begin Button2.WindowProc := FOriginalButtonProc; FOriginalButtonProc := nil; end; Button2.Caption := 'Admin'; Button2.Repaint; end; But, that being said, since you are drawing the entire button anyway, you may as well just use the BS_OWNERDRAW style and handle the WM_DRAWITEM message, as explained earlier in this discussion thread.

That is because you are drawing outside of a painting event. As soon as the button gets repainted for any reason, your drawing is lost. This is why you must owner-draw the button so that any custom drawing can be persisted across multiple paint events.

I don't think you need to call WsocketErrorDesc() as ESocketException also has an ErrorMessage property.

Have you tried calling WSAGetLastError() directly? At the point where OnError is called, the last socket error code might not have been overwritten yet. The error code is stored in the raised ESocketException in its ErrorCode property. Sounds like a bug that should be reported to the ICS author.