Dave Nottage

What is the correct way? Unfortunately, that is easier said than done. The process which loads the DLL runs only when an app is run on Citrix, and it makes the calls to DriverOpen etc immediately, and once the process fails it needs to be restarted, which makes it nigh on impossible to attach to the process that is loading the DLL, let alone debug it. For the first point: I'll need to double check that tomorrow, however given that everything works 100% of the time on most machines, I figure it's unlikely. For the second point: in what ways might this happen? For the third point: That's the reason why I have the exception handler, if I can make it work

Regarding going down the route of a "pure" Delphi DLL: The DLL needs to link to a .lib file that is provided with the SDK. Since Delphi cannot link to .lib files, I needed to extract the .obj file (there is only one in the .lib) and link to that. There are 9 symbols that need to be linked to: 2 are "direct" static links that look like this: function _Load(pLink: PDLLLINK): Integer; cdecl; external name '_Load'; function VdCallWd(pVd: PVD; ProcIndex: USHORT; pParam: PVOID; puiSize: PUINT16): Integer; stdcall; external name '_VdCallWd@16'; I'm not sure of the correct terminology for it, however the other 7 symbols are the functions that need to be "implemented", including DriverOpen, however because of name mangling, they're exported with symbol names like this (e.g.): _DriverOpen@12. Since it's impossible to name Delphi functions with an "@" symbol, I used ObjConv to rename the symbols, removing the @12 and while I was at it, the underscore. This results in, for example, DriverOpen being declared thus: function DriverOpen(pVd: PVD; pVdOpen: PVDOPEN; puiSize: PUINT16): Integer; stdcall; I cannot add "external" and "name" for these functions because they need to be "implemented", rather than "direct" static links. Again, not sure of the exact terminology for this distinction. In this "pure" Delphi DLL mode, everything compiles OK and Citrix loads the DLL successfully, however for one reason or another it never calls DriverOpen (at all, in this mode), which apparently (as per my original post) it usually calls first. It does however call the DriverInfo function, and does so successfully. Note that the only function that is exported is the Load function (as per their C examples). The Load function is documented as doing the work of setting up a call table to the other functions. Thanks regarding the HND type and pLibMgrCallTable ; I have now corrected that. As far as the "pure" mode goes, this made no difference, however. Back to the "conduit" mode: I had set up some logging to dump what values are coming into the C DLL, and into the Delphi DLL, and see what goes back from Delphi to C, in case there was something untoward happening, and I've discovered that although the DriverOpen function in the Delphi DLL actually completes, it does not return to the calling point in the C DLL, i.e. there's a problem somewhere in between. I put in an exception handler, but I guess it's not right: char* IntToStr(int Number) { char Result[50]; sprintf(Result, "%d", Number); return(Result); } int HandleException(unsigned int code, struct _EXCEPTION_POINTERS *ep) { char Msg[512]; strcpy(Msg, "Exception code : "); strcat(Msg, IntToStr(code)); OutputDebugString(Msg); return EXCEPTION_EXECUTE_HANDLER; } int DriverOpen(PVD pVd, PVDOPEN pVdOpen, PUINT16 puiSize) { OutputDebugString("WSCitrix Conduit DLL DriverOpen called"); if (LoadDelphiDLL()) { __try { int result = DelphiDriverOpen(pVd, pVdOpen, puiSize); OutputDebugString("WSCitrix Conduit DLL DriverOpen returned from Delphi"); return(result); } __except(HandleException(GetExceptionCode(), GetExceptionInformation())) { } } } i.e. it calls DelphiDriverOpen (which completes in the Delphi DLL), but never reaches the subsequent OutputDebugString My limited C skills are probably shining through 😉

Going by the source, it appears it is called when the IDE first goes "idle", and it fires off a thread to do the check, so I doubt the delay is from the "phone home" check. FWIW, I see no noticeable delay with version 1.1.6.959

The URL you are sending to does not appear to have any of the required values. It should (according to the link you gave) look at least something like this: https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=de

Application.MainForm, oddly enough Not really enough to go on - why do they need to be suppressed? i.e. why would they even show at the point when the IDE is shutting down?

For what purpose? That may define exactly what the add-in should "look for". One way might be to use a timer to monitor the Visible property of the main form. As far as I know, the only time it becomes invisible is when the IDE is shutting down

This issue would be a part of the problem: https://quality.embarcadero.com/browse/RSP-21834

ProcessMessages will not work as you may expect in FMX, and definitely not on Android. I suggest avoiding ProcessMessages entirely; then it won't matter which framework or platform you're using. It may be better to describe why you think it's necessary to use it (preferably with example code), because it's likely there are other ways to solve it.

+1000 for SourceTree on macOS. Not as enthused about the Windows version

The DW.OSDevice.xxx units here have implementations for GetDeviceName for iOS, Android, macOS, Windows and Linux: https://github.com/DelphiWorlds/KastriFree/tree/master/Core I could add something like GetUserName - which would likely return blank for iOS and Android

It's probably Jeremy North's XE Plus Pack: http://jed-software.com/xepp.htm I'll point him in this direction

The post titles? If so, why?

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?