Search the Community

Am I correct that V9 is supposed to work on OSX? I am attaching a basic project that does nothing but have the needed ICS components on a form, linked together appropriately. It seems to build fine if I use the {$DEFINE FMX} Conditional but when I launch it, it freezes as shown in the attached CPU stack below. Any advice would be greatly appreciated as I'd really like to use this component as it seems so much faster than the built-in HTPPS components. Cheers, Ken Schafer ICS-V9 OSX Test Project.zip stack.txt

My project has been working and deploying correctly to Windows and macOS, release / debug, 32/64 Windows and 64/ARM 64 Mac Today deploying to any macOS version hangs, no error message, need to go into task manager to shutdown Delphi. I haven't changed or upgraded Delphi, Windows, or macOS. Is there a way to invoke a default deployment configuration?

I am getting different behaviour with a FireMonkey project between Windows 32-bit and macOS 64-bit In the windows version the message shows when I close the form, but not in OSX. I may be being a bad person once again with my form handling, but it all worked a treat in 10.4 with no signs of memory leaks 🤪 procedure TForm1.Button1Click(Sender: TObject); var f : TForm2; begin f := TForm2.Create(nil); try f.ShowModal; finally f.Free; end; end; procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction); begin showmessage('Form2 FormClose'); end;

The FMX.InAppPurchase component already implements in-app purchase for iOS, and since OSX uses the same StoreKit library, I simply added an OSX copy of the iOS implementation and adjusted it to "work" on OSX. It works as far as it compiles and runs, and I can call "QueryProducts", which also initiates a Delegate callback. Once in a while I can even successfully read the product details from App Store that I receive in the callback, but most of the time the callback fails with an AV. It seems to be random where it fails. If I restart paserver before each run I can increase the chance that it works, but except from that I did not find any correlation between changes I have made and a successful request. The testprogram works fine on iOS. On OSX I have tried to target both Mojave and Cataline, and both 32 bit and 64 bit editions. They all fail. As the OSX code is the same as the iOS code, I guess that the problems are related to differences between the iOS and the OSX target in the Objective-C handling and wrapping. Any ideas what could be wrong, or what I should try? (or maybesomeone with more knowledge about Objective-C wrapping and the inner workings of Delphi could help me with this?) Below are some extracts from the code in my new unit "FMX.InAppPurchase.Mac". My test program creates TiOSInAppPurchaseService and call QueryProducts. It works without errors, and a few seconds later the TiOSProductsRequestDelegate.productsRequest callback is called. From here random AV's happens. Usually it fails on the first line FIAPService.FProductList.Clear, and sometimes it fails earlier in "DispatchToDelphi" or later in one of the following lines. TIAPProductList = class(TList<TProduct>) end; procedure TiOSInAppPurchaseService.QueryProducts(const ProductIDs: TStrings); var ProductIDsArray: NSMutableArray; ProductIDsSet: NSSet; ProductID: string; begin ProductIDsArray := TNSMutableArray.Create; for ProductID in ProductIDs do ProductIDsArray.addObject(PStrToNSStr(ProductID)); ProductIDsSet := TNSSet.Wrap(TNSSet.OCClass.setWithArray(ProductIDsArray)); FProductsRequest := TSKProductsRequest.Wrap(TSKProductsRequest.Alloc.initWithProductIdentifiers(ProductIDsSet)); ... FProductsRequest.setDelegate((FProductsRequestDelegate as ILocalObject).GetObjectID); FProductsRequest.start; end; constructor TiOSInAppPurchaseService.Create; begin ... FProductsRequestDelegate := TiOSProductsRequestDelegate.Create(Self); FProductList := TIAPProductList.Create; end; constructor TiOSProductsRequestDelegate.Create(const IAPService: TiOSInAppPurchaseService); begin inherited Create; FIAPService := IAPService; end; procedure TiOSProductsRequestDelegate.productsRequest(request: SKProductsRequest; didReceiveResponse: SKProductsResponse); begin FIAPService.FProductList.Clear; ... end;

Hi, First time here (just got the Google Groups and it has died). Look, this might be a simple issue and if it is I apologise, but it is driving me spare. Reading the literature I was under the impression you could build for OSX and use the debugger as you would in say a Win32 app,ication, ie. you would have breakpoints and could single step through the code if required. When I build for OSX I have never seen anything like this. The Event Log always says 'No Debug Info'. The best I have been able to do is to use log.d from FMX.Types to show log messages in the PAServer window. I really have tried searching everywhere and anywhere and cannot see anything that would enable what I would call 'normal' Delphi debugging. I think I have all of the necessary debug options set (the debugger certainly works as expected when I build the code for Win32/Win64). Specifically this was a working 32 bit application and DLL that I have converted to a macOS app and DYLIB. I can get the DYLIB to load and functions called if I have a simple test application as the host NOT the converted application. The reason it is now quite desperate is that I'm getting an AV and here's the scenario: Delphi 10.2.3 OSX 10.13.6 PAServer 19.0 Xcode 9.4.1 So my issue with code: Main Program and My Dylib Both call a common unit that generates log file (log4pascal as modified by me) At startup I get Log.d message that now in Initialize Block of log4pascal (it sets up logging for the DYLIB and main application) I then get a Log.d message code is in the Initialize Block of the DYLIB I then get a log.d message that code is leaving the Initialize Block of the DYLIB (all good so far) I SHOULD now get a log.D message that it is entering the Initialize Block of the Unit associated with the main application Instead I get an AV - see attached OSX AV And the PASERVER log shows the same - See log-lines below So the Initialize Block code for the main unit for the application itself is a Log.d line, it NEVER gets executed, ie. the AV occurs before it gets to Initialize? I am having significant difficulty tracking this error. So my initial problem is essentially ...how do i get the debugger to work when running an OSX application so that I can track down that AV (ie. with features like setting breakpoints and single stepping through the code??? Or do I have this all wrong, is there some other way I should be doing it (the Embarcadero documentation suggests I should be able to debug OSX in the same way as I debug Win32 apps). Again, if this is simple stuff I apologies, but it has me stuck.... Kevin