Dave Nottage

It's a work in progress. The plan is for the 64-bit IDE to eventually be able to do everything the 32-bit IDE can.

Thanks for the heads up! To follow on from my earlier code example: procedure TForm1.FormSafeAreaChanged(Sender: TObject; const AInsets: TRectF); begin Padding.Rect := AInsets.Round; end; Basically ensures that controls on the form do not encroach on the "safe" areas.

All that was added (and it appears it was not documented), was control over whether or not the "opt out" flag is set: If you leave it as true, you shouldn't need to do anything special for your app. If you change it to false, Android will apply edge-to-edge rules, so you'll need to cater for any areas that go outside the "normal" area. Once Android start enforcing targeting of Android 16, there will be no choice, as they will be taking away the option to opt out. Exactly. There is also the issue of the color of the status bar items - if your "opt in" and your form background is on the "bright side", you could use this code to make status bar items "dark": uses Androidapi.Helpers, Androidapi.JNI.GraphicsContentViewText; constructor TForm1.Create(AOwner: TComponent); begin inherited; TAndroidHelper.Activity.getWindow.getInsetsController.setSystemBarsAppearance( TJWindowInsetsController.JavaClass.APPEARANCE_LIGHT_STATUS_BARS, TJWindowInsetsController.JavaClass.APPEARANCE_LIGHT_STATUS_BARS ); end;

It's probably because TMainMenu is not themed in the IDE. As you probably know, the IDE itself uses TActionMainMenuBar, which is themed. Curious that submenu items are themed, though.

Yes. I'd file a report.

You could try Mathias at his email, which is on the site. If no response, you could also try contacting someone at madVR, of which he is co-founder. Given what is happening there, he may be really busy with that.

Looks like the Optimization switch (off) kills the hint

Still does not for me. EDIT: Are you using the 64-bit IDE?

Not for me. Did you try it with assertions turned off?

Sounds like it. Thanks for the heads up!

I believe you mean Delphi 13.0, however the answer is no. Bear in mind that it appears Flutter overcame this issue only last month, after it being outstanding for them for 2 years.

Something wrong with this one.?

I was right, but it took a bit of hoop jumping: uses Androidapi.JNIBridge, Androidapi.JNI.Widget, Androidapi.Helpers, Androidapi.JNI.GraphicsContentViewText, Androidapi.JNI.JavaTypes, Androidapi.JNI.App; function FindTimePickerFragment(out AFragment: JDialogFragment): Boolean; var LFragmentManager: JFragmentManager; I: Integer; LFragment: JFragment; begin LFragmentManager := TAndroidHelper.Activity.getFragmentManager; for I := 0 to LFragmentManager.getFragments.size - 1 do begin LFragment := TJFragment.Wrap(LFragmentManager.getFragments.get(I)); if JStringToString(LFragment.getClass.getName).EndsWith('.TimePickerFragment') then begin AFragment := TJDialogFragment.Wrap(LFragment); Result := True; Break; end; end; end; function FindTimePicker(const AView: JView; out ATimePicker: JTimePicker): Boolean; var I: Integer; LSubView: JView; LViewGroup: JViewGroup; begin Result := False; if TJNIResolver.IsInstanceOf(AView, TJViewGroup.GetClsID) then begin LViewGroup := TJViewGroup.Wrap(AView); for I := 0 to LViewGroup.getChildCount - 1 do begin LSubView := LViewGroup.getChildAt(I); if TJNIResolver.IsInstanceOf(LSubView, TJTimePicker.GetClsID) then begin Result := True; ATimePicker := TJTimePicker.Wrap(LSubView); Break; end else if FindTimePicker(LSubView, ATimePicker) then begin Result := True; Break; end; end; end; end; procedure TForm1.TimeEdit1OpenPicker(Sender: TObject); var LTimePicker: JTimePicker; LFragment: JDialogFragment; begin if FindTimePickerFragment(LFragment) and FindTimePicker(LFragment.getDialog.getWindow.getDecorView, LTimePicker) then LTimePicker.setIs24HourView(TJBoolean.JavaClass.init(True)); // or False end;

Sadly, for Android you'd need to "reinvent" the TimePickerFragment class in the Java source (for fmx.jar) located in source\rtl\androiddex\java\fmx\src\com\embarcadero\firemonkey\pickers\defaults\TimePickerFragment.java. In onCreateDialog, it returns a new instance of TimePickerDialog, passing DateFormat.is24HourFormat for the is24HourView flag. This value cannot be changed afterwards, so it'd be pointless to even find the TimePickerDialog instance at runtime (if it were possible), and it won't be possible to change what value is passed without altering the Java source, which means rebuilding fmx.jar (ugh). If it were me, for Android I'd forget TTimeEdit, and implement my own time picker in Java. EDIT: Actually, I've since discovered there is a TimePicker involved, so it might be possible to traverse the view hierarchy as was done for iOS, to find it and call setIs24HourView.

Presumably you are using the BarcodeReader functionality? There are no paths set for iOS simulator in the demo for that, mainly because there's no camera access on iOS simulator. If you are really set on compiling for simulator anyway, ensure that the project search paths are set for the iOS Simulator target, like what is set out in these instructions.

Yes, as long as all other required meta-data is present. Well done!

Since you mention iOS: uses Macapi.ObjCRuntime, Macapi.Helpers, iOSapi.UIKit, iOSapi.Helpers, iOSapi.Foundation; function FindUIDatePicker(const AView: UIView; out ADatePicker: UIDatePicker): Boolean; var I: Integer; LSubView: UIView; begin Result := False; if AView.subviews.count > 0 then begin for I := 0 to AView.subviews.count - 1 do begin LSubView := TUIView.Wrap(AView.subviews.objectAtIndex(I)); if LSubView.isKindOfClass(objc_getClass('UIDatePicker')) then begin Result := True; ADatePicker := TUIDatePicker.Wrap(AView.subviews.objectAtIndex(I)); Break; end else if FindUIDatePicker(LSubView, ADatePicker) then begin Result := True; Break; end; end; end; end; function GetLocale(const AIs24Hour: Boolean): NSLocale; var LIdent: NSString; begin if AIs24Hour then LIdent := StrToNSStr('en_GB') // I say, old chap else LIdent := StrToNSStr('en_US'); // Yeehaw! Result := TNSLocale.Wrap(TNSLocale.OCClass.localeWithLocaleIdentifier(LIdent)); end; procedure TForm1.TimeEdit1OpenPicker(Sender: TObject); var LDatePicker: UIDatePicker; begin if FindUIDatePicker(TiOSHelper.SharedApplication.keyWindow.rootViewController.view, LDatePicker) then LDatePicker.setLocale(GetLocale(True)); // or False, for 12 hour // else it was not found end; FindUIDatePicker iterates the native view hierarchy looking for the UIDatePicker. The alternative would have been to "hack into" FMX.Pickers.iOS. Note: By default, the locale property of UIDatePicker is nil, which means it uses whatever the device setting is (Settings > General > Date & Time). If a locale is assigned, it uses the default time mode for that locale. As long as the default time mode does not change for the two used in the code, it should remain working.

Sorry, I forgot about this issue. (I blame my aging brain) Which is another good reason to keep up with the latest version of Delphi, especially when targeting mobile.

Just checked System.ZLib from 12.2 against 12.3 - no changes there. It would be odd if ChromeOS or Chromebooks left out this library, so perhaps it is failing to load due to an incompatibility? This, from Google: "We are not aware of any issues with public API, but struct layout in particular has changed over time and will likely continue to do so. Note that new API in later zlib versions will obviously not be available on OS versions that predate the API. It is possible to avoid all these problems (at the cost of increased APK size) by always using the static libz.a instead of libz.so."

It's very possible that you need to correct something. For the steps related to deployment of AndroidManifest.xml, once again: 1. Deploy the project in the desired mode (Debug or Release) at least once so that the AndroidManifest.xml file is generated (obviously you do not need to do this on this occasion, since you already have) 2. Copy AndroidManifest.xml from the Debug or Release folder to, for example, the root of the project folder 3. Modify the meta-data entry in the copy of AndroidManifest.xml to: <meta-data android:name="com.google.android.play.billingclient.version" android:value="7.1.1" /> 4. Disable the default deployment of AndroidManifest.xml, and add a deployment for the edited AndroidManifest.xml (to the same remote path, which is .\): I just did this myself, even though I was using Delphi 12.3 (I just changed the version value in the meta-data to something different), deployed for app store and the resulting AndroidManifest.xml in the .aab file is correct.

I expect you've missed (or somehow it has changed) at least the last part of this, notably: disabling the original deployment of AndroidManifest.xml and adding the edited version to the deployment.

Go to the cloud console. Select your project (if it does not do that automatically) - the Project ID value should be just under where is says welcome Click on APIs & Services Click on Credentials If it already lists a Desktop OAuth credential in the OAuth 2.0 Client IDs list, click on the download action at the very far right - that will display the Client ID and Client Secret If there is no existing Desktop OAuth credential, click Create Credentials (at the top), select OAuth Client ID, then Desktop app, etc See the comment in the INI file as to how to get the RefreshToken value. I expect that RADServer will populate this value once it has obtained it.

Implementation for an OnNmeaListener here: https://github.com/DelphiWorlds/Kastri/blob/6d21cdb8000c43e7bcc7a0dc44bcbad1058106e1/Features/Location/DW.Location.FusedLocation.Android.pas#L44 ..adding it to LocationManager here: https://github.com/DelphiWorlds/Kastri/blob/6d21cdb8000c43e7bcc7a0dc44bcbad1058106e1/Features/Location/DW.Location.FusedLocation.Android.pas#L212 I have no idea how to use what is actually in the message - someone else asked for the implementation I came up with.

It's not intended.

This is not necessarily true given past experience, however it has been true for a while now. Having said that, even if you discover that your install of Delphi does not work with the latest version of Xcode, it is possible to revert to an earlier one. It should be borne in mind however that (at time of writing) App Store requires at least Xcode 16. Side note: those using Delphi CE will find that (at time of writing) it will not work with Xcode 16 unless you take special measures.