Dave Nottage

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...

Thanks! I should have known there was a third-party group.. next time I'll post there 🙂

I am having only one issue (so far) when compiling from source: the "Insert A Favorites Entry in the File Menu" option in Favorite FIles Options is not persisted.

I compiled from source for Rio - no AV on exit

TStreamReader.Create (fileName) passes the flags as: fmOpenRead or fmShareDenyWrite Sadly, none of the overloads allow you to change this. Worse still: its counterpart TStreamWriter.Create can fail on platforms other than iOS because the flags don't include fmShareDenyWrite

I have issues sometimes with older devices (not being able to debug), but on the whole no other issues. I use a VirtualBox VM running Windows 10, on my MacBook Pro running macOS 10.14.1. My current devices are a Nexus 5X and a Samsung Tab A 7 (SM-T380) One thing I will advise to anyone doing serious Android development is to become very familiar with a logcat viewer such as Monitor, which comes with the "original" Android SDK.

Is there an issue with using GetDocumentsPath (which in the deployment manager for Android translates to assets/internal), or subfolders thereof? Alternatively, use KodeZwerg's solution. GetHomePath in deployment manager translates to ., i.e. the root

As you've discovered, "normal" permissions do not need to be requested at runtime, so there's no point in doing so.

I'm hoping DelphiAST is updated to handle it soon after Rio is released (or beforehand) :-)

OK.. now my aggregator detects a "keyword alerts" feed.. not exactly what I was after 😉 Edit: False alarm.. I need to learn how to use it better. No feeds at all still

How do you get an RSS feed? I can't seem to find any links indicating RSS.