Remy Lebeau

Windows doesn't just arbitrarily screw up files. You must have done something to cause the files to be screwed up, ie loading them or saving them with the wrong charset. You need to use the proper charset when saving/loading files. That's where you need to fix the problem, not in the code that has already loaded the files, by then the data is already corrupted. If you have ANSI files, load them with an ANSI charset. If you have UTF-8 files, load them as UTF-8. Period. If you need to differentiate, use a BOM or other metadata, or hieristic analysis. Don't guess the encoding.

That's a little misleading. SChannel can use the SSL/TLS protocol. So, even if the server were using OpenSSL, a client could connect to it using SChannel. In any case, there is a 3rd party GitHub repo that provides an SChannel IOHandler for Indy. But DataSnap doesn't use that. Also, IIRC, it is only available for clients not servers. iOS is the only platform that Indy statically links to OpenSSL. On all other platforms, including Android, it uses OpenSSL libraries that are already present on the device, unless you provide your own lib files with your app.

That error message does not imply OpenSSL specifically. It could be any SSL library. dbExpress itself doesn't use any SSL DLLs, that's the job of the underlying dbExpress driver to decide what it needs. To remove such a dependency, you will likely need to find another dbExpress driver that supports your database engine without that dependency.

Hard to diagnose without seeing your actual setup - how the BPLs load the images, how the EXE loads the BPLs, how the EXE assigns the images to its UI, etc. Lots of factors here.

What does "template" mean from your code's perspective, though? Are your Forms using a common base class? A common styling theme? Something else? Doubtful, but anything is possible.

The behavior you describe suggests your code is handling certain window messages incorrectly, like WM_(SYS)COMMAND or WM_CLOSE. Or your OnClose event handler is doing something weird. The VCL's default behavior when closing a window is to either terminate the app (if closing the MainForm) or hide the window (non-MainForm). The Win32 API's default behavior when closing a window is to destroy the window. Hard to diagnose your problem one way or the other without seeing actual code that reproduces the issue. What does your Exit menu do, exactly? Does it simply close the calling Form, or does it terminate the whole process? Also, you mention a template, what does that mean, exactly?

Yes, exactly. By using variables of interface type, you don't need to free the instances yourself, as interfaces are reference-counted. There is no leak in your example.

That wasn't what was shown originally, but whatever. My answer is the same. You need to create an instance of a class that implements the IThriftHashSet interface, and then you can pass that instance into the function. For example: var hashSet: IThriftHashSet<TProduct_info_type> := TThriftHashSetImpl<TProduct_info_type>.Create; // or: var hashSet := TThriftHashSetImpl<TProduct_info_type>.Create as IThriftHashSet<TProduct_info_type>; hashSet.Add(terminal_packaged_part_number); // etc ... var info: IProduct_info := product_get_info(hashSet); // or: var info := product_get_info(hashSet); Yes, exactly. TThriftHashSetImpl implements IThriftHastSet, so that is the correct type to create an instance of. Yes, you can. Add() is public in the IThriftHashSet interface itself. It is protected only in the implementation of the interface. You don't need access to the implementation, only to what the interface provides. So, it is important that you call Add() on a variable whose type is IThriftHashSet not TThiftHashSetImpl.

There is no callback in the Memory Manager. If it can't allocate memory, it will raise an exception. Period. If you to customize the behavior, you can provide your own allocation function using SetMemoryManager(), then your function can do whatever you want. But, know that there can be only 1 Memory Manager installed, so for instance if you want to use FastMM or other 3rd party Memory Manager along with your own, you will have to chain them together manually. --- UPDATE: actually there is a callback - the System.ErrorProc callback. If the Memory Manager fails to allocate, ErrorProc() will be called if assigned, specifying ErrorCode=reOutOfMemory. A default error handler is installed by the SysUtils unit, and it raises an EOutOfMemory exception. If no ErrorProc is assigned, the calling process is Halted instead. So, you could assign your own ErrorProc if you want to do something different, however by the time the Memory Manager calls ErrorProc(), it is too late to retry the allocation. If you provide your own allocation function using SetMemoryManager() instead, then you can do your own re-allocation attempt if you want to.

It is expecting you to pass in an instance of the TProduct_info_type class, not the class itself. No. product_get_info() will create the object for you and return an interface pointer to that object. You just need to declare a variable of type IProduct_info to receive it.

DNS servers are just servers like any other. And the OS acts as a client like any other. Like any client/server system, servers can go down at times, network routes to servers can go down at times, etc. The Internet doesn't have 100% connectivity 100% of the time. Hiccups happen. All you can do is make sure your software is robust enough to handle network errors when (not if) they happen, retry operations as needed, and move on.

Maybe WinMD in GetIt is only available for 12.2 or 12.3? CE is still at 12.1.

I simply used the debugger at runtime to modify the CallingConvention parameter of the internal System.Rtti.Invoke() function that DoGetValue() calls for a getter method. DoGetValue() is hard-coded to pass in a value of ccReg, I just changed that to ccCdecl instead, and then the AV went away. That is at least a POC that the issue could be fixed if DoGetValue() were made to be more sensitive to the getter's actual RTTI. And likewise for DoSetValue(), too.

Actually, calling convention is part of the RTTI for invokable types, including class methods. But TRttiInstanceProperty.DoGetValue() (and DoSetValue()) are ignoring that fact and just assume Delphi's default Register convention when invoking the property getter/setter. If I change the invocation to specify Cdecl instead of Register, then no crash occurs. I have opened a bug ticket for this: RSS-3574: AV in TRttiProperty if getter/setter does not use Register calling convention

Or, use TThread.ForceQueue() instead, eg: procedure TFprincipal.FontNameRClick(Sender: TObject); begin TThread.ForceQueue(nil, procedure begin ga_TipoLetra := FontNameR.Text; Font.Name := ga_TipoLetra; gn_FontSize := StrToInt(ComboSize.Text); Font.Size := gn_FontSize; Screen.MessageFont := Font; ToolBar.Font.Size := Min(gn_FontSize, 14); end); end;