Remy Lebeau

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.

You should not need to resort to this. The VCL already calls UnregisterClass() and RegisterClass() after CreateParams() exits. The purpose of CreateParams() is just to report the class details that the control wants, not to manipulate the registration directly.

That is a very dangerous approach. Don't do it that way. First, there is no guarantee that accessing the ClassName on an invalid object will raise an exception. And second, reading from invalid memory may cause other side effects (ie, page faults, etc). Since your integers are very small, then you could simply look for integers first, and treat higher values as objects since they should never reside at such low memory addresses, eg: const MaxObjIntValue = 8; ... var value := NativeInt(Objects[c,r]); if (value >= 0) and (value <= MaxObjIntValue) then begin // is an integer, use value as needed... end else begin // is an object, use TObject(value) as needed... end ... if NativeInt(Objects[c,r]) > MaxObjIntValue then Objects[c,r].Free;

How does that code have anything to do with the discussion at hand? Also, why would you not simply use TImage.Picture.LoadFromFile() and let it handle everything for you? procedure LoginImage(const RutaBase: string); var filename : string; begin // Intentar cargar como BMP filename := IncludeTrailingPathDelimiter(RutaBase) + 'flogin.bmp'; if FileExists(filename) then begin imgFLogin.Picture.LoadFromFile(filename); end else begin ShowMessage('File not found') end; end;

Yes, and this is documented behavior: https://docwiki.embarcadero.com/Libraries/en/Vcl.Graphics.TPicture.Bitmap Where it says "a Metafile or Icon graphic", it really means "any non-Bitmap graphic" instead. Use the TPicture.Graphic property when you need to access as-is whatever TGraphic descendant is currently loaded in the TPicture. Use the TPicture.Bitmap property instead when you specifically need a TBitmap.

Check the TImage.Picture.Graphic and TGraphic.Empty properties: if (Image1.Picture.Graphic = nil) or Image.Picture.Graphic.Empty then You can assign nil to the TImage.Picture property: Image1.Picture := nil; // same as: // Image1.Picture.Assign(nil); Or to its Graphic property: Image1.Picture.Graphic := nil;

Another option might be to use tagged pointers. Normally, objects are aligned in memory in such a way that certain bits in object pointers are always zero, so those bits can be repurposed if you are careful. For instance, if you limit your integer values to 31 bits (x86) or 63 bits (x64), you can use an unused bit in an object pointer to flag whether the pointer holds an integer value vs an object address, and just mask off the bit when extracting the value. For example: // this assumes objects are never stored at an odd-numbered memory address.. var intValue: Integer := ...; Objects[c,r] := TObject((NativeUInt(intValue) shl 1) or $1); ... var objValue: TObject := ...; Objects[c,r] := objValue; ... if (NativeUInt(Objects[c,r]) and $1) <> 0 then begin // is an integer... var intValue := Integer(NativeUInt(Objects[c,r]) shr 1); ... end else begin // is an object... var objValue := Objects[c,r]; ... end; ... if (NativeUInt(Objects[c,r]) and $1) = 0 then Objects[c,r].Free;

Correct. You can't. So, either store all objects only, or all integers only. Don't mix types. But, if you must, then you'll need to either wrap the integers inside of objects, or add an extra header in front of each value to identify its type, etc.