Leaderboard

Yes, like that, but use TThread.Queue. There's no need to block the worker thread while memo is being updated.

You could try to write the except statement with the else syntax to see if it gets caught. I had to do this in web core, null items will raise an exception that are a special exception. try ... except on E: Exception do Logger.Warn('Failed app tool init : ' + E.Message, self); else // handle everything else Logger.Warn('Failed app tool init', self); end;

There is a case, though: if the code inside the try block calls something in a DLL and that DLL function does not trap any exceptions raised inside the DLL code these would bubble up the exception handler stack into your try except block, be trapped there but not recognized as deriving from the Exception class. This would even be the case if the DLL is written in Delphi, unless DLL and EXE are build with the same Delphi version and with run-time packages enabled for both projects.

When the client's ConnectTimeout property is set to a non-infinite value, or if you are connecting the client in the context of the main UI thread and using TIdAntiFreeze, then Indy uses a worker thread to connect the client socket to the server in order to implement timeout handling. The call stack above is showing the exception being raised in the context of that worker thread, and there is no way for you to catch that specific exception directly from that thread. However, Indy will internally catch the exception for you and re-raise it in the context of the thread that is trying to connect the client. And you should be able to catch that exception normally. If not, then the RTL is likely not doing its job correctly (IIRC correctly, Delphi's exception handling on MacOS is less stable/reliable than on Windows). The code you have shown is fine, you should be able to catch the exception. So, you are just going to have to debug the code at runtime to find out why the exception is not being propagated to your code correctly.

Not the raw data as it came directly from the TCP socket, no. By the time you are given access to the TIdHTTPRequestInfo object, all of the raw socket data has already been parsed and re-organized for Indy's purposes. That being said, you can get the (near-raw) headers from the TIdHTTPRequestInfo.RawHeaders property, and the body data from either the TIdHTTPRequestInfo.PostStream or TIdHTTPRequestInfo.FormParams property, depending on the request's media type. Basically, yes. The only other option is to log the raw socket data immediately as it comes off the socket, before Indy parses it. You can do that by assigning a TIdConnectionIntercept-derived object to the AContext.Connection.Intercept property in the server's OnConnect event. For instance, one of the TIdLog... components, like TIdLogFile,

Today it's an example. Tomorrow you or somebody else sees the code and use it in a real application. Copy paste errors are always a fun thing to search for or debug.

TThread.Synchronize and TThread.Queue are parts of core RTL functionality. You can use them and they are appropriate way to synchronize any Delphi code with main thread, regardless of what other libraries you are using. BTW, following line also needs to be synchronized with main thread. memo1.append(datetimetostr(now)+': Start Processing');

That's an interesting approach, never seen it before. 🤔 To this day, I also go with try .. except Rollback; raise; end

A tool to simplify source code search. Find where class or function is declared, where class descendants are declared, search only in comments or in strings, etc. Build for Delphi and written in Delphi from scratch. Detailed description: https://delphihtmlcomponents.com/codefinder.html

Corruption of the stack can mess up SEH I guess.

Uploaded the latest version - you can download from https://files.spring4d.com/UsesHelper/latest/UsesHelperSetup.zip

https://delphisorcery.blogspot.com/2021/04/testinsight-12-released.html

I don't see why there should be compromise. I want great tools and efficient code output.

There's a post in Quality Central with a workaround: [RSP-39445] Firemonkey android app PhoneDialer block applications startup - Embarcadero Technologies