Hans♫

This must be a bug in Delphi, but it seems to be out of my hands, so for now we just replace our JPG files with PNG files. However, in case someone would experience similar problems or want to look into it, here is what I have found. We load the exact same jpg file using the exact same code, but the result: Windows: OK iOS: OK Android: OK MacOS not Sonoma: OK MacOS Sonoma with ARM processor: OK MacOS Sonoma with Intel processor: Exception Stacktrace: System.Error(System.TRuntimeError)(reInvalidOp) System.FRaiseExcept(unsigned int, bool)(1,true) System._Round(long double)(NaN) Fmx.Multiresbitmap.TBitmapOfItem.DoChange()($000060000198c420) Fmx.Graphics.TBitmap.BitmapChanged()($000060000198c420) Fmx.Graphics.TBitmap.SetSize(int, int)($000060000198c420,3000,1496) Fmx.Graphics.TBitmap.AssignFromSurface(Fmx.Surfaces.TBitmapSurface*)($000060000198c420,$0000600003388c00) Fmx.Graphics.TBitmap.Assign(System.Classes.TPersistent*)($000060000198c420,$0000600003388c00) Fmx.Graphics.TBitmap.LoadFromStream(System.Classes.TStream*)($000060000198c420,$0000600002846a80) Uoscommon.LoadBitmapResource(Fmx.Graphics.TBitmap*, System.UnicodeString)($000060000198c420,'HomeBackGround2048') Fomain.tMainForm.FormCreate(System.TObject*)($00007fd5090cfa00) Fmx.Forms.TCommonCustomForm.AfterConstruction()($00007fd5090cfa00) System._AfterConstruction(System.TObject*)(0x7fd5090cfa00) Fomain.tMainForm.tMainForm(System.Classes.TComponent*)($00007fd5090cfa00,true,$00007fd509907af0) Fmx.Forms.TApplication.CreateForm(System.Classes.TComponentClass, void*)($00007fd509907af0,0x1021a0bd0,0x1021a46d0) Fmx.Forms.TApplication.RealCreateForms()($00007fd509907af0) Fmx.Platform.Mac.TPlatformCocoa.Run()($00007fd508715880) Fmx.Forms.TApplication.Run()($00007fd509907af0) main(1,0x7ff7bfeff8e0,0x7ff7bfeff8f0,0x7ff7bfeff9a0) :00007FF80ED623A6 ?? It happens when calling "Round" in this procedure: procedure TBitmapOfItem.DoChange; begin inherited; if (FBitmapItem <> nil) and (not FBitmapItem.FDormantChanging) then begin FIsChanged := True; FBitmapItem.FWidth := Round(Width); //<- exception here. Width is an integer property with value 3000 FBitmapItem.FHeight := Round(Height); if (FBitmapItem.Component <> nil) and ([csLoading, csDestroying] * FBitmapItem.Component.ComponentState = []) and (FBitmapItem.Collection is TCustomMultiResBitmap) and (TCustomMultiResBitmap(FBitmapItem.Collection).UpdateCount = 0) then FBitmapItem.Changed(False); end; end; The Round function being called that raises the exception: function _Round(Val: Extended): Int64; type TWords = Array[0..4] of Word; PWords = ^TWords; begin if (PWords(@Val)^[4] and $7FFF) >= $403F then FRaiseExcept(feeINVALID); Result := llrintl(Val); end; The image being loaded is added to the project as a ressource with the ID "HomeBackGround2048", which refers to a JPG image with dimensions 3000x1496. We load it using this function: procedure LoadBitmapResource(const aBitmap: TBitmap; const aResourceName: string); var lStream: TResourceStream; begin lStream := TResourceStream.Create(HInstance, aResourceName, RT_RCDATA); try aBitmap.LoadFromStream(lStream); finally lStream.Free; end; end;

Thank you. It looks like the exact same problem, but interesting that it has been reported for Ventura. With our code the error does not happen in Ventura, only on Sonoma.

It's strange that we have not had any reports from iOS 17 users, and our own tests on iOS 17 also runs fine. Our analytics tells us that 400 unique users have started our software on iOS 17 until yesterday. We use in-app purchases too and those two .release lines are still active in our copy of FMX.inAppPurchase.iOS.pas. We have other modifications of the file though, so maybe it makes a difference just by compiling it your self?

With a very short notice, Google Play shows this warning:

If Marco Cantu reads this, I would highly recommend Embarcadero to prioritize a rock solid compatibility to new SDK/API version on alle platforms. New features are nice, bug fixes are very nice, but the uncertainty about support for platform changes can ruin it all. I know it is easier said than done because the marketing people will scream for new features to promote. That is the tradeoff in all software companies. But the whole revenue in our company is based on being available on all platforms, and it requires "nerves of steel" to be so close to the edge of the cliff so often.

Thank you, I did not see this option. I applied and we now have an extended deadline until November 1st.

I see that someone also created an issue in Quality Portal about this: https://quality.embarcadero.com/browse/RSP-42164

Ok, last time we tried to go ahead of the default API level in Delphi, we had a lot of trouble. Looks like this is still the case... I think for now we will try to get our next update out before the deadline.

We already use a new installation of Delphi 11.3 Patch 1, but it targets API level 32. It installs this: file:///C:/Users/Public/Documents/Embarcadero/Studio/22.0/CatalogRepository/AndroidSDK-2525-22.0.47991.2819/platforms/android-32 What did you do to target API level 33? PS. It is installed on a VM that had Delphi 11.2, but upon installation of Delphi 11.3 it uninstalled 11.2 first.

Thanks for your kind offer. We managed to solve it on our own, and have used it for a while now.

Interesting what happens when the Vietnamese language is chosen. I created this issue 7 years ago, about another error that I had only seen on Vietnamese: https://quality.embarcadero.com/browse/RSP-16205 It could be related to your problem because my reported error is that TPath.GetTempPath fails in Vietnamese. PS. I don't understand Vietnamese, but we have customers from Vietnam and had to make a workaround for the issue.

We use this function (I modified it here to avoid using external references, but I think it will be correct as written here): function OSGetUserDesktopPath: string; begin {$ifdef MSWINDOWS} winApiUtils.GetFolderPath(CSIDL_DESKTOPDIRECTORY,Result); result := result+TPath.PathSeparator; {$elseif defined(OSX)} Result := TPath.GetHomePath+TPath.PathSeparator+'Desktop'+TPath.PathSeparator; {$elseif defined(IOS)} Assert(false, 'OSGetUserDesktopPath not implemented on IOS'); Result := ''; {$elseif defined(ANDROID)} Assert(false, 'OSGetUserDesktopPath not implemented on ANDROID'); Result := ''; {$else} {$Message Error 'Missing Target'} {$endif} end;

We just released a new update of our software yesterday, built with Delphi 11.2. Unfortunately our customers now complains that keyboard shortcuts no longer works. This has already been reported in quality portal, but unfortunately we did not discover this in time: https://quality.embarcadero.com/browse/RSP-39902 The problem happens in Actions with all F1 - F12 shortcuts, numerical keyboard shortcuts and more. Except from that, our Delphi 11.2 built app works well on all platforms (Windows, Mac, Android and iOS).

This is the first time I install a Delphi 11 version on my computer, having used Delphi 10.4 so far. The installation runs until the page where I should choose what platforms to install (see image). First time I actually did see the list, but as soon as I checked additional options (maybe at the time where I checked iOS target, not sure), it crashed. Having uninstalled and installed again several times, but always the same result: Both web installer and ISO installer. Both as Administrator or not. All Delphi 11 editions, 11.0, 11.1 and 11.2. I am on Windows 10, latest update, and have Delphi 10.4 on the computer with all taget platforms installed and in use (Win, OSX, iOS and Android). Something may be interfering? Any ideas what to try?

The problem has been solved. I contacted Embarcadero support and they suggested to check the "Controlled Folder Access" in Windows 10. I had it turned on, and after turning it off, I could install Delphi 11.2 without any problems.

Thank you for your reply, but where do you see Windows available on the screen shot? There are no platforms on the list. The Exception comes apparently from the installers attempt to update the list of platforms. Pressing Continue just closes the installer (crash).

Unfortunately that is not even possible. If you look at the screen dump, the list of platforms is empty, so I cannot install just Windows. It did show the list of platforms first time I ran the installer, but it doesn't any more. Not sure what has changed.

Windows 10, latest version. I have updated my post.

This could also be due to differences in hardware and configuration. How many devices have you tested for each Android version?

Ok, I use 10.4.2 (27.0.40680.4203 ), but most important: the problem is there in the latest Delphi 11.

If you close the modal window with the red button in the title bar, then FormClose and FormCloseQueury are not called on MacOS. However, this problem was also there in Delphi 10.4, so it might not be the same issue you are facing. I recently reported this bug here: https://quality.embarcadero.com/browse/RSP-39547

We have made the "SetSystemText" function below, to replace the hardcoded dialog strings. It works on all platforms including iOS and Android (thought we have had problems with only a partial implementation in MacOS in previous Delphi versions - not sure if it has been fully implemented yet). It is a part of our own language handling class, but the idea is that fLines is a list of text lines loaded from a language file, where the ID is defined by a constant. Just replace this with your own source of translations. The "LoadLangFromStrings" procedure is in FMX.Types. procedure tProgStr.SetSystemText; var lStrList: TStringList; begin //Load list of translations for use everywhere the "Translate" function is used in Delphi. lStrList := TStringList.Create; lStrList.AddPair(SMsgDlgInformation, fLines[cStrInformation]); lStrList.AddPair(SMsgDlgError, fLines[cStrError]); lStrList.AddPair(SMsgDlgConfirm, fLines[cStrConfirmation]); lStrList.AddPair(SMsgDlgWarning, fLines[cStrConfirmation]); //<- We don't have the "Warning" text translated lStrList.AddPair(SMsgDlgYes, fLines[cStrYes]); lStrList.AddPair(SMsgDlgNo, fLines[cStrNo]); lStrList.AddPair(SMsgDlgCancel, fLines[cStrCancel]); lStrList.AddPair(SMsgDlgClose, fLines[cStrClose]); lStrList.AddPair(SMsgDlgOK, fLines[cStrOk]); lStrList.AddPair(SMsgDlgHelp, fLines[cStrHelp]); lStrList.AddPair(SMsgDlgHelpHelp, fLines[cStrHelp]); LoadLangFromStrings(lStrList); lStrList.Free; end;

We have a few users that experience freezing and very slow response in our Android App. In Google Play Console, we get these ANR messages: The app works on 99% of the devices, so it is not a general problem, and we cannot reproduce it on our devices. What can be the reason for these problems? Another user has posted a StackOverflow question about this a year ago - but no answers: https://stackoverflow.com/questions/66657413/how-to-solve-anr-on-android-firemonkey PS. Could it be related to this warning ("Non-SDK API: Landroid/view/MotionEvent") that we also have? https://stackoverflow.com/questions/70350726/delphi-11-app-in-android-play-store-shows-warning-non-sdk-api

Thanks Dave! To achieve the best user experience we would like to use the install-time assets. We need to extract a 150 MB binary file to be accessed using traditional file methods, and had hoped that your demo app also supported install-time assets. As you mention, the only part missing is to extract and save the file using AssetManager. Any chance that this could find it way into your demo project?

Hi Dave, Thanks for your reply, it's greatly appreciated. Now Video1 and Video3 get downloaded when adding the call to FAssetDelivery.Fetch in the IdleMessageHandler. So the fast-follow & on-demand delivery modes both work correctly. And the videos are playing as well. However, the install-time asset Video2 still does not show up. But I wouldn't have expected that the above fix would have solved that either. You write in the code: //!!!! Install time packs are just "normal" assets Do you see Video2 showing up in your app? Maybe I'm wrong but as I read the android developer documentation the install-time asset pack will be available immediately at app launch, but that's only the apk and you need to access the assets in it thru the AssetManager API. See this diagram. I assume the solution in our case could be to use AssetManager API stream interface to make a copy of the file in a temporary location. Do you agree? Thanks again for your help!