Remy Lebeau

Well, then the hint is valid since the value -1 will never be used.

Did they update Abort() to mark it with the new 'noreturn' attribute?

Have you tried changing the Size property of the VCL's global TScreen.MenuFont?

This is explained in the DocWiki documentation: https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#Unified_internal_version_numbers_to_37

Yes. Major version releases can coexist with each other. It's minor version releases that can't.

The Community edition does not support offline installation or offline registration.. You need a Paid edition for that.

Forcing use of client/server components on specific ports does not provide security. Nor are your "secret" ports actually very secret, they are easily discoverable. Also, the server has no way to know if the client is even listening on the "secret" port before replying, so there's no security in favoring one port over another. If you want true security, use a proper security protocol, like DTLS. Also, using an asynchronous server component to receive 1 response is not making the client faster and simpler, it's actually making the client slower and complex (multi-thread handling, breaking up code flow, etc), and it goes against one of Indy's core designs - linear writes and reads in command/response models. But whatever. It's your business design, do what makes sense to you. What do I know? I'm just the guy who maintains the components you are basing your work on. Good luck.

I have some issues with your implementation: IPv6 networks are not supported. The client request is needlessly wordy. The client broadcasts to 255.255.255.255 instead of to the subnet's actual broadcast IP. Some routers block traffic to 255.255.255.255 by default. In case the client is run on a machine with multiple networks installed (VPN, etc), there is no option to let the user decide which network to broadcast to. The client is using separate UDP sockets to send the request and read replies. You are forcing the client to receive on a specific listening port. The server is not sending its reply back to the real port that actually sent the request. Most routers will block this traffic if port forwarding is used. On the server side, always reply to the sending port. On the client side, either 1) let TIdUDPClient read replies on its sending port, or 2) let TIdUDPServer send the request on its listening binding. Use one or the other, not both. Doesn't use Indy's TIdStack.GetLocalAddressList() method to discover local networks (at least on Windows, as it may have issues on Android). Since your goal is to allow a TCP client to discover a server, I would opt to get rid of the TIdUDPServer on the client side, and just use TIdUDPClient by itself. Send a request, read a response, done. You don't need to make that process asynchronous with TIdUDPServer in most use cases. Using TIdUDPServer on the client side makes more sense if you want to discover multiple servers and then let the user choose between them, or to leave it open so servers can just broadcast their presence over time.

Why? You said you are creating IDE design-time packages. So they run in the IDE process, and the IDE is not itself a cross-platform application, it is a Windows-only VCL application. What am I missing? Can you provide more exact details of what you are actually trying to accomplish?

System.Classes.RegisterClass()? It is not clear what you are actually looking for. Please clarify. Can you provide an example of what you want to accomplish? Maybe using custom window messages, or System.Messaging.TMessageManager ? Are they separate packages in the same process, or are they in separate processes? It makes a big difference depending on whether you have to cross the process boundary or not. There is nothing like that framework in the common RTL. And it wouldn't make sense anyway if your two units can't share a common unit that defines what they need to share.

If I'm reading your codes correctly, you are both assuming that ReturnAddress() itself doesn't have a stack frame, and it is returning the address stored in its caller's stack frame. Which means it won't work correctly if its caller has no stack frame, or if it is called from inside of an inline function.

Never heard of CleanTalk. Are you putting your code snippets in code blocks (the `</>` button on the editor toolbar)? I'm guessing you did not read the ICS documentation. It says: https://wiki.overbyte.eu/wiki/index.php/TWSocketServer On a side note: `while PeekMessage() = False do WaitMessage();` is the exact same as calling `GetMessage()` without a loop. Makes sense, if you are creating a TCP server socket expecting it to receive UDP traffic. You need a UDP server socket.

Can you provide the actual code you are having trouble with? Did you set the component's MultiThreaded property to true? Does your thread have a message loop?

"The only way I currently see would be to attach to that program after it has been executed. But that's rather cumbersome."

The only useful tidbits I get from that page are that: the Start Menu doesn't display two shortcuts pointing to the same target the Start Menu tries to block showing Uninstallers. Good to know. Seems to be on track with what I'm seeing.