Remy Lebeau

Why were you using ShellExecute() for that? You should have been using CreateProcess() instead. To detect when the process ends, use WaitForSingleObject() or related function on the returned process handle. On Linux, you can start an external process using the fork(), exec...(), or posix_spawn() functions. To detect when the process ends, use wait() on the returned process ID.

Why are you using AnsiString at all? You should be using (Unicode)String instead, since that is what the TMemo expects. In any case, Char is WideChar in D2009+, so SizeOf(Char) is 2 not 1, so you are allocating memory for your AnsiString for only 1/2 of the file data, but then reading the full file into that memory. So you are going to corrupt surrounding memory. Use SizeOf(AnsiChar) instead, which is 1 so you can just drop the SizeOf() altogether. var LoadString: AnsiString; FS: TFileStream; begin FS := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone); try SetLength(LoadString, FS.Size); FS.ReadBuffer(Pointer(LoadString)^, FS.Size); finally FS.Free; end; Memo.Lines.Add(String(LoadString)); end; Alternatively, there are other options, such as TMemoryStream.LoadFromFile(): uses System.Classes; var LoadString: AnsiString; MS: TMemoryStream; begin MS := TMemoryStream.Create; try MS.LoadFromFile(FileName); SetString(LoadString, PAnsiChar(MS.Memory), MS.Size); finally MS.Free; end; Memo.Lines.Add(String(LoadString)); end; Or TStreamReader: uses System.Classes, System.SysUtils; var LoadString: String; Reader: TStreamReader; begin Reader := TStreamReader.Create(FileName, TEncoding.ANSI); try LoadString := Reader.ReadToEnd; finally Reader.Free; end; Memo.Lines.Add(LoadString); end; Or TFile.ReadAllText(): uses System.IOUtils, System.SysUtils; var LoadString: String; begin LoadString := TFile.ReadAllText(FileName, TEncoding.ANSI); Memo.Lines.Add(LoadString); end;

I can see that being true for Standard RTTI (TypInfo.pas), which is only generated for published members. But that should not be true for Extended RTTI (Rtti.pas), which sees everything, even private/protected stuff. That is why TRttiMember has a Visibility property.

You can use Extended RTTI for that. TRttiMethod has a VirtualIndex property.

Feel free to file a bug report with Embarcadero.

The only way I could see that happening is if either: - the requests are being sent on the same TCP connection (using HTTP keep-alives and maybe HTTP pipelining) and one of the requests is blocking the ones that arrive after it - your requests are arriving on different TCP connections and are accessing some piece of shared data/functionality that is being blocked/deadlocked, thus blocking all requests that try to access it. It is really hard to know what is going on without more details about your code and the requests. The only option is to close the socket that belongs to that TIdContext. But if your code is blocked/deadlocked on something that is not related to the socket itself, then closing the socket is likely to not have any/much effect in this situation. You really need to narrow down WHAT exactly is blocking. You still haven't answered my earlier questions about that.

Sounds like a bug that you should report to Embarcadero directly.

Since Delphi 2010, actually. RTTI data is pooled in memory. There is only 1 ref-counted copy of the RTTI data in memory that all active TRttiContext instances share. That article is old, and not 100% accurate. For instance, the implementation of TRttiContext.Create() shown in the article is how Create() was implemented in D2010, but it was changed in XE. Test1 is creating and destroying the RTTI pool 100 times, because it only has 1 TRttiContext instance alive at a time. The pool's refcount never goes above 1. The pool is recreated each time the refcount is incremented to 1, and destroyed when the refcount is decremented to 0. That is not the case in Test2, which has 2 active TRttiContext instances alive at a time so the pool is not destroyed until after the loop is finished.

What is the actual problem you are experiencing? You did not provide any details whatsoever about that. Are you getting an error? Corrupted data? Which version of Indy are you using? How is the Java server configured? Which SSL/TLS version(s) does it expect? Please be more specific. With the code you have shown so far, the SSLIOHandler uses only TLS 1.0 by default. Does the server support TLS 1.0? Many servers nowadays no longer support TLS 1.0 and earlier, they expect TLS 1.1 or 1.2 at a minimum. You can enable TLS 1.1 and 1.2 in the SSLIOHandler's SSLOptions.SSLVersions property (only sslvTLSv1 is enabled by default).

I think you mean the external DLL uses your jpeg, right? What failure exactly? You need to be more specific. What makes you think TJPEGImage creates invalid JPG files? Perhaps the real problem is an error in how the DLL uses the JPG file.

He said the code is running in a thread. Locking a TBitmap's Canvas is required when working with a TBitmap in a thread, otherwise the main VCL thread can swoop in at any time and reclaim the GDI resources being used by the TBitmap behind its back.

Nothing has been announced publicly yet.

Or email the RAD Studio beta directly: rad.beta@embarcadero.com

Oh, that's interesting. I just tried it on my desktop, and sure enough it takes on the mobile look&feel when I shrink my browser window (I always use it full screen, so I never noticed that before).

When I first started using this site on mobile, it took me a LONG time to find the option there. Definitely not the most intuitive place for it. I would have expected it to be under "Activity" along side the "Unread Content" option.

I don't understand what is confusing about it. Actions have several properties and events that apply to Forms just as they do to any other UI control.

The same could be asked for any UI control that has a published Action property and a published OnClick (or other actionable) event. One reason is code reuse, the same Action object can be assigned to multiple controls, even the Form itself. For instance, Actions are commonly shared with menu items and other UI controls that invoke the same actions. Another use would be sharing common properties with multiple controls (Enabled, Visible, etc) so you can update 1 property and have it propagate to multiple controls automatically.

Sadly, you won't be able to do that with FMX's TWebBrowser. It simply doesn't have the necessary functionality for that (only VCL's TWebBrowser does). If you really want to use FMX's TWebBrowser, then I suggest using TIdHTTP or other HTTP client for the actual HTTP communications, that way you can automate it however you want, and just use TWebBrowser to display the HTML (or whatever) you retrieve, such as via its LoadFromStrings() method. And then use TWebBrowser events to block the browser from making HTTP requests, redirecting them to your HTTP client of choice. The experience won't be as seemless as a standard browser, but it will give you more control.

A better solution would be to forgo the TWebBrowser frontend altogether and redesign your web app to accept REST requests on the backend server to do the work you need. Then use a standard UI on the client side to display the results as needed. You would have to check if the underlying platform browsers provide any APIs to automate them in code. VCL's TWebBrowser is a wrapper for Internet Explorer and exposes access to its DOM API. FMX's TWebBrowser does not expose similar functionality.

Correct. There is not, because you cannot combine 32-bit and 64-bit code into a single executable, so you will need separate 32-bit/64-bit DLLs, and thus will need separate 32-bit/64-bit processes to install their hooks into target 32-bit/64-bit processes.

Despite its name, UCS4String is not actually a native string type, like (Ansi|Raw|UTF8|Unicode|Wide)String are. It is just a dynamic 'array of UCS4Char', so a null UCS4Char is added to the end of the array to allow for null-terminated-string semantics, ie you can type-cast a UCS4String to PUCS4Char and iterate the string up to the null terminator, just like any other null-terminated P(Ansi|Wide)Char string. UCS4String was introduced way back in Delphi 6 (when UTF8String was first added as just an alias for AnsiString), so it couldn't be added as a true native string type back then. They never made UCS4String into a native string type, even though the RTL is now flexible enough to support a native string with 4-byte characters. All of the necessary plumbing was added in Delphi 2009 when UnicodeString was first introduced and UTF8String was turned into its own unique string type. UCS4String could easily be made into a native string type now, if they really wanted to. They probably haven't done so yet because UCS4String is very seldomly used by anyone, so they likely didn't want to waste development resources on it. Yes, because Length() is simply returning the full array length, which includes the null UCS4Char at the end.

It was introduced in Delphi 2007 for .NET, so it might not have been available on the Win32 side yet.

The TDictionary in question is the FFormRegistry member of the FMX.Forms.TApplication class. It is used internally by TApplication in its CreateForm(), CreateMainForm(), RegisterFormFamily(), and GetDeviceForm() methods. For what reason, I have no idea.

Yup, I've been in the exact same boat. That's why my big monolithic (C++Builder written) app still works fine for over 2 decades, and our .NET ported web-based app doesn't 🙂

That implies that a non-nil TObject is being released by ARC, and the TObject itself is likely invalid. That call stack shows the global TApplication object being destroyed, which in turn is destroying an internal TDictionary<String, TList<TFormRegistryItem>> object. Looks like perhaps the destruction of one of the stored TFormRegistryItem objects is what is crashing.