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;

You are not checking if either TRttiContext.GetType() or TRttiType.GetProperty() are returning nil before accessing the objects they return. procedure TFormSimpleDraw2.Button2Click(Sender: TObject); var Value: TValue; LType: TRttiType; RttiContext: TRttiContext; CaretPositionProp: TRttiProperty; CaretPosition: TCaretPosition; begin RttiContext := TRttiContext.Create; LType := RttiContext.GetType(Memo1.ClassInfo); if LType = nil then Exit; // <-- add this CaretPosition := Memo1.CaretPosition; CaretPositionProp := LType.GetProperty('CaretPosition'); if CaretPositionProp = nil then Exit; // <-- add this Value := CaretPositionProp.GetValue(Memo1); ... end;

Why not use Screen.Fonts instead?

Calling Free() on a nil pointer is perfectly safe. So that means you must be calling Free() on a non-nil pointer that is NOT pointing at a valid TBitmap object. Did you make the adjustments I showed you to give each TListItemData its own TBitmap object? Also, DO NOT use both OnClose and OnDeletion events to free the same memory. Use one or the other. The OnDeletion event is the preferred place to free custom data stored in a TListView, as it is called every time a TListItem is removed from the TListView, even during shutdown. I've used this technique many times in the past, so I know it works.

All of your list items are pointing at a single TBitmap object in memory, so all of them will show the last image that was loaded from the DB. If you want to show a separate image for each list item, they each need their own TBitmap object, eg: type PListItemData = ^TListItemData; TListItemData = record theString: string; ThePicture: TBitmap; end; ... procedure TMyForm.RunQueryAndFillListView; var ClipItem: TListItem; ListItemData: PListItemData; begin ... while not FDQuery2.Eof do begin ... ClipItem := lvClip.Items.Insert(0); New(ListItemData); try ListItemData.theString := s.Text; ListItemData.ThePicture := nil; if ContainsText(s.Text, 'Picture') then begin BlobField := FDQuery2.FieldByName('Image') as TBlobField; Stream := FDQuery2.CreateBlobStream(BlobField, bmRead); try ListItemData.ThePicture := TBitmap.Create; ListItemData.ThePicture.LoadFromStream(Stream); finally Stream.Free; end; end; ClipItem.Data := ListItemData; except ListItemData.ThePicture.Free; Dispose(ListItemData); end; FDQuery2.Next; end; ... end; ... // TListView.OnDeletion event handler procedure TMyForm.lvClipDeletion(Sender: TObject; Item: TListItem); var ListItemData: PListItemData; begin ListItemData := PListItemData(Item.Data); if ListItemData <> nill then begin ListItemData.ThePicture.Free; Dispose(ListItemData); end; end;

First off, you posted a screenshot of code that appears to contain an actual live app password in it. I suggest you delete that screenshot, invalidate that app password, and generate a new one. Don't EVER post live credentials to an online forum! Now then... What does Indy's IdSSLOpenSSLHeaders.WhichFailedToLoad() function report after the error has occurred? All of the DLLs on the GitHub page have been tested with Indy and known to be working. There isn't a releases section. That repo is just a collection of downloadable files. From https://github.com/IndySockets/OpenSSL-Binaries No, that is the best place. However, if you wanted to put them somewhere else, you can do that, too. You would just have to call Indy's IdSSLOpenSSLHeaders.IdOpenSSLSetLibPath() function at runtime to tell Indy where the DLLs are located.

There is no OnPurchaseRestored event in TInAppPurchase. Did you mean OnPurchaseCompleted instead? Oh. QueryPurchases() is an internal method that is called by another internal method QueryInventory() which is called only at the end of setting up a new connection to the BillingClient.

That is because you are clearing the FPurchaseMap before then querying the Products instead of querying the Purchases. IsProductPurchased() looks at FPurchaseMap, but QueryProducts() populates FProductDetailsMap and not FPurchaseMap. QueryPurchases() populates FPurchaseMap. Also, there is no OnPurchasesRequestResponse event for when QueryPurchases() completes. It triggers the OnSetupComplete event instead. Which implies QueryPurchases() was not intended to be used outside of initial component setup, since TInAppPurchase tracks purchase updates in real-time.

Have you tried calling the overloaded version of TDirectory.Copy() that takes an IgnoreErrors parameter and set it to False? The overload of TDirectory.Copy() that you are calling implicitly uses IgnoreErrors=True. When IgnoreErrors=False then a failure to copy files will raise an EInOutError exception, containing a list of all the files that failed to copy and the reason(s) why they couldn't be copied. Are you getting that exception?

Yes, as a result of this post on StackOverflow a few day ago: How to get updated subscription status after cancellation without restarting the app (Google Play Billing in Delphi)? Hopefully, considering they did confirm on the ticket that it is a problem. Rather than clearing the whole Inventory, I was thinking it could instead just remove individual items that are no longer in the queried purchase list. True, it won't query the whole list. But it does listen for new purchases in real-time and add them individually to the Inventory. But I don't think it listens for subscription changes, that is a whole different workflow that the component is not setup to handle.

Did you report the problem to Embarcadero? It is either an error in the documentation, or a bug in the compiler.