Dave Nottage

Hasn't happened to me. Any that you can share?

Does this link (followed from the SO link) not give enough info? http://francois-piette.blogspot.com/2013/02/using-universal-plug-and-play-upnp-with.html

Thanks for the heads up! For anyone else interested, here's a link: https://developer.tomtom.com/maps-sdk-ios

I'm curious as to how they've made it work, unless it uses an older Google Maps SDK. Delphi 10.3 Rio will not link against the frameworks in the latest Google Maps SDK version, even targeting iOS 11.2 SDK

I've just noticed this from your first post. I can only suggest checking what the differences are between the two. Perhaps make a copy of the converted application, and start removing parts of it until the problem is resolved.

Is there a callstack?

So that it's consistent with the overuse of padding in the IDE?

..or a refurbished model (including iMac or Macbook); preferably no earlier than 2013 to ensure that it'll run Mojave.

What is the exact error message? Can you ping the address from a command line window in your VM? I'm using VirtualBox VM's myself and have not had an issue with either NAT or Bridged, as long as the VM can "see the address" being connected to.

I have tested 10.3 on an Android 5.1.1 device and it updates the UI just fine

I am trying to fathom why the web install and ISO install apparently has different versions of .DCUs (or perhaps source). Check the last comment, here: https://quality.embarcadero.com/browse/RSP-18836 They must be being packaged from different sources; the question is why on Earth are they?

No suggestions as yet, however it has been reported: https://quality.embarcadero.com/browse/RSP-22314

Can you show how/where JInterstitialAd is being used?

Whatever the reason, I've reported the problem: https://quality.embarcadero.com/browse/RSP-22877

I can't see how it could have ever worked. The code for registerIntentAction in FMXNativeActivity.java: public void registerIntentAction(String action) { mRegisteredIntentActions.add(action); } ..and where it is initialized: private List<String> mRegisteredIntentActions = Arrays.asList(NotificationInfo.ACTION_NOTIFICATION, NotificationPublisher.ACTION_GCM_NOTIFICATION); Arrays.asList returns a fixed size list: https://developer.android.com/reference/java/util/Arrays.html#asList(T...) i.e. it cannot be added to. Attempting to add anything will raise the error that you're seeing.

That's the *target* version, not *mininum*. They are quite different things. Delphi 10.3 Rio also raised the minimum (i.e. minSdkVersion value) to 19, which excludes devices that have lower than Android 4.4 (Kitkat), hence the warning from Google Play. Having said that, Google claim that less than 2.5% of devices are on lower than 4.4 anyway. EDIT: weird - for some reason I could not see other replies before I sent this. Worse: I can't seem to delete this reply?

Not sure exactly which forum this fits in, so I've posted this here. Some background: Citrix allows developers to create their own "Virtual Channel" DLLs using their SDK: https://www.citrix.com/community/citrix-developer/xenapp-xendesktop/virtual-channel-sdk.html Originally, I attempted to produce such a DLL purely in Delphi, however I was not able to make Citrix make the required calls to the DLL, so (long story short), I created a "conduit" DLL in C that loads a Delphi DLL and redirects all the required calls to it. Over time, I have built functionality into the Delphi DLL, and it has all been working fine; that is up until I attempted to add support for scanning using DelphiTwain: http://kluug.net/delphitwain.php The problem now: The mere fact that the DelphiTwain code is linked in to the DLL causes it to crash within Citrix. I am not creating any of the classes, and therefore none of the actual DelphiTwain code actually executes - there are no class constructors or unit initialization code, unless there is something implicit that I don't know about. Regardless of all that, the DLL actually successfully loads. There is a certain sequence of calls that Citrix makes when loading the DLL, and I have logging to show when these events occur. It is only when it reaches a certain point that the "crash" occurs, which for those who are familiar with Citrix Virtual Channels, happens somewhere between the call to DriverOpen and DriverSetInformation. I have spent a fair amount of time attempting to track down the issue, including producing a "cut down" version of DelphiTwain in order to isolate what code is being included that causes the "crash". There appears to be no rhyme or reason as to why certain parts of the non-executing code would affect it in this way, so I'm reaching out here in case someone is able to shed some light on it. As an example, recently I discovered for this section of code: function TTwainSource.GetEnumerationValue(Capability: TW_UINT16; var ItemType: TW_UINT16; var List: TGetCapabilityList; var Current, Default: Integer; Mode: TRetrieveCap; MemHandle: HGLOBAL): TCapabilityRet; var EnumV: pTW_ENUMERATION; ItemSize: Integer; Data: PAnsiChar; //ccc CurItem: Integer; Value: string; Container: TW_UINT16; begin {Call method to get the memory to the return} if MemHandle = 0 then Result := GetCapabilityRec(Capability, MemHandle, Mode, Container) else begin Result := crSuccess; Container := TWON_ENUMERATION; end; if (Result = crSuccess) and (Container <> TWON_ENUMERATION) then begin Result := crInvalidContainer; GlobalFree(MemHandle); Exit; end; {If result was sucessfull and memory was allocated} if (Result = crSuccess) then begin {Obtain structure pointer} EnumV := GlobalLock(MemHandle); {Fill return properties} Current := EnumV^.CurrentIndex; Default := EnumV^.DefaultIndex; ItemType := EnumV^.ItemType; {Prepare to list items} // ItemSize := TWTypeSize(ItemType); //!!!!!!!! Citrix crash (non-running code) Data := @EnumV^.ItemList[0]; SetLength(List, EnumV^.NumItems); {Copy items} for CurItem := 0 to EnumV^.NumItems - 1 do begin {Obtain this item} // GetItem(Value, ItemType, Data); // Value := GetItemValue(ItemType, Data); // List[CurItem] := Value; {Move memory to the next} inc(Data, ItemSize); end; {Unlock memory and unallocate} GlobalUnlock(MemHandle); GlobalFree(MemHandle); end {if (Result = crSuccess)} end; As can be seen by my comment, having the line that calls TWTypeSize causes a "crash", whereas commenting it out does not. TWTypeSize looks like this: function TWTypeSize(TypeName: TW_UINT16): Integer; begin {Test the type to return the size} case TypeName of TWTY_INT8: Result := sizeof(TW_INT8); TWTY_UINT8: Result := sizeof(TW_UINT8); TWTY_INT16: Result := sizeof(TW_INT16); TWTY_UINT16: Result := sizeof(TW_UINT16); TWTY_INT32: Result := sizeof(TW_INT32); TWTY_UINT32: Result := sizeof(TW_UINT32); TWTY_FIX32: Result := sizeof(TW_FIX32); TWTY_FRAME: Result := sizeof(TW_FRAME); TWTY_STR32: Result := sizeof(TW_STR32); TWTY_STR64: Result := sizeof(TW_STR64); TWTY_STR128: Result := sizeof(TW_STR128); TWTY_STR255: Result := sizeof(TW_STR255); //npeter: the following types were not implemented //especially the bool caused problems TWTY_BOOL: Result := sizeof(TW_BOOL); TWTY_UNI512: Result := sizeof(TW_UNI512); TWTY_STR1024: Result := sizeof(TW_STR1024); else Result := 0; end {case} end; Again, this is code that is *never* even executed, because none of the classes from DelphiTwain are even created. Sadly, Citrix's diagnostics are insufficient to discover what the problem is. I'm hoping that someone might have an idea of why this might happen.

No, the DelphiTwain code uses dynamic binding, and only attempts to load the Twain DLL when the Delphi Twain object is created, which is not even happening yet. Regardless, why would the Citrix VC load sequence succeed with that line of code (for example) commented out (when the routine is not even executed at all - I have had log statements inserted before as a sanity check), and not succeed if it isn't?

It will be an issue if the Android tools don't support it, and nothing EMBT can do anything about.

You need to explicitly request those permissions at runtime. Check out the CameraComponent demo in: \Users\Public\Documents\Embarcadero\Studio\20.0\Samples\Object Pascal\Mobile Snippets\CameraComponent Also, there's no such permission as CAMERA_EXTERNAL_STORAGE. I expect you mean READ_EXTERNAL_STORAGE

Earlier I said: "You will probably need to change that to the corresponding path for your JDK version 7 (mine is C:\Program Files\Java\jdk1.7.0_80)"

Your PATH is still pointing to C:\Program Files\Java\jdk-9.0.1\bin. (it's in the first few lines of the output you provided) This tool makes it easy to change it: https://www.rapidee.com

That's not strange; you can have a base SDK that started from 25.x.x and add later platforms and build tools using the Android SDK Manager, which is exactly what I've done on my systems. If you analyze the message, you will see that it can be a problem with the command that follows the ampersand (&), i.e. the one that starts with: "C:\Users\Xor-el\Documents\Embarcadero\Studio\19.0\PlatformSDKs\android-sdk-windows\build-tools\28.0.3\dx.bat" If you check the Output tab of the messages window, it has more detail about the error. It's likely to be that dex is failing, and is likely to be because of a JDK mismatch. I see you have in your path: C:\Program Files\Java\jdk-9.0.1\bin You will probably need to change that to the corresponding path for your JDK version 7 (mine is C:\Program Files\Java\jdk1.7.0_80)

I log in there daily, usually, but yeah.. RSS or something would be nice.

With the release of RAD Studio 10.3 Rio comes the release of Codex 1.1.0: https://www.delphiworlds.com/codex/ Which reminds me: I need to add version history 🙂 Coming soon...