Dave Nottage

If it's other than in the project folder, you need to set the Source path in the Debugger section of the Project Options:

Works OK here. My steps: 1. Create a blank FMX app, change platform to OSX 64-bit 2. Add a button and memo 3. Add the code you described 4. Save the project 5. Open FMX.Memo.pas from the source, and save it in the same folder as the project 6. Put a breakpoint in TCustomMemo.GetText 7. Close the file in the editor 8. Run the app with debugging 9. Click the button. IDE opens the local copy, as expected, and stops at the expected breakpoint

A stack trace would be more helpful. It should appear after you click "Break". If not, click View > Debug Windows > Call Stack or just use Ctrl-Alt-S

Those paths look suspiciously like mine in Kastri Free. What exactly are you compiling? I suggest checking whether you have a unit that references the DLL without having a conditional define, or that the path to it is included for macOS when it should not be

If you are using Delphi 10.3, for this situation you do not need to modify AndroidManifest.template.xml yourself. Unless you have other customizations to it, please delete it (or remove your <provider> changes). Go to the Project Options, select Application > Entitlement List and check the Secure File Sharing checkbox.

Right; that would be because, as I said earlier, it is "shown only when permissions are not granted by the user"

You need to trace through the TAndroidPermissionsService.InternalRequestPermissions method in the System.Android.Permissions unit. Note that the rationale is shown only when permissions are not granted by the user.

I found out from Dmitry Arefiev. It really should have been included in the release notes.

libcgsqlite3.dylib is now a "featured" file. Go to Deployment Manager and use the Add Featured Files to add it.

FindComponent returns nil if you misspell the name, so just check for nil?

The difference is it is loaded by RDS. I could put together code that just replicates the problem, if you're able to help with it

Tested this again today. Using TransferMode := ttmMemory, ScanTest.bmp is the result using the "standalone" DLL, and ScanTestA.bmp is the result using the "RDS" DLL. ScanTest.bmp ScanTestA.bmp

Yes, with a different failure; can't recall exactly. I'll check again tomorrow.

You're right, it should be, and I changed it to THandle (same as used by GlobalLock) for hNative in the TransferImages method, and the Handle parameter in the ReadNative method, but to no avail - same problem. The handle numbers are larger, e.g: In the "standalone" DLL: 57278728 (36A0108) In the "RDS" DLL: 2333671976 (8B190228) and 1541866024 (5BE70228)

That's pretty much what I've needed to do, i.e. remove all that are not in the correct order, then insert in the correct order

Instead of using Edit Custom Style for every component that we want a background color on, I came up with some code similar to this: type TEditEx = class(TEdit) private FColor: TAlphaColor; function GetBackgroundRectangle: TRectangle; procedure InternalSetColor(const Value: TAlphaColor); procedure SetColor(const Value: TAlphaColor); protected procedure ApplyStyle; override; published property Color: TAlphaColor read FColor write SetColor; end; procedure TEditEx.ApplyStyle; begin inherited; InternalSetColor(FColor); end; function TEditEx.GetBackgroundRectangle: TRectangle; var LStyleObject: TFmxObject; I: Integer; begin Result := nil; LStyleObject := FindStyleResource('rect'); if LStyleObject = nil then begin LStyleObject := FindStyleResource('background'); if LStyleObject <> nil then begin Result := TRectangle.Create(LStyleObject); Result.StyleName := 'rect'; Result.Align := TAlignLayout.Contents; Result.HitTest := False; Result.Stroke.Kind := TBrushKind.None; Result.Fill.Color := TAlphaColorRec.Null; Result.Parent := LStyleObject; end; end else Result := TRectangle(LStyleObject); end; procedure TEditEx.InternalSetColor(const Value: TAlphaColor); var LRectangle: TRectangle; begin LRectangle := GetBackgroundRectangle; if LRectangle <> nil then begin FColor := Value; LRectangle.Fill.Color := FColor; end; end; procedure TEditEx.SetColor(const Value: TAlphaColor); begin NeedStyleLookup; ApplyStyleLookup; InternalSetColor(Value); end; A side-effect of this code is that the inner parts of the edit control can be selected in the Object Inspector, like this: Any ideas of what I've done wrong, and how to remedy it?

We have a winner! Thanks

1.3.12.66 doesn't crash on exit for me. I guess I'm behind the times? 😉

I'll have to check mstsc and RDP-session after the weekend, but the others are 64-bit. Regardless, the DLL succeeds in enumerating the sources, the scanning progress dialog shows, and it completes the scan; it is only when it reaches the ReadNative method and calls GlobalLock that there's an issue - why would all that comes before it succeed? Yes, it's non-zero.

Not on the remote machine no, since it does not have the scanner connected; the local machine does, where the RDS DLL resides. In this call, rc can be one of TWRC_XFERDONE, TWRC_CANCEL, or one of the error values. In this case, it is returning TWRC_XFERDONE (which is why it proceeds to the ReadNative call, where the error occurs, as per one of my earlier messages) so one would hope that it is returning a valid value for hNative. As far as GlobalLock is concerned, it apparently is not.

The TOSDevice record in this unit: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.pas Has a ShowFilesInFolder method, which "re-routes" to the respective platforms, namely macOS and Windows. For macOS: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.Mac.pas For Windows: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.Win.pas

That is correct. This is what I mean: https://docs.microsoft.com/en-us/windows/win32/termserv/virtual-channel-client-dll So yes, RDS; I'm just used to the other terminology. As above, the DLL is on the same machine as the Twain driver. RDS loads the DLL when a session is started to the remote application, which communicates to the virtual channel client DLL via RDS. The remote application notifies the virtual channel to scan an image, and the DLL makes calls via the Delphi Twain code to enumerate the sources, and start scanning an image. The scanning "in progress" dialog shows OK, however the code fails in TTwainSource.ReadNative, as described earlier. The identical code to allow the user to select the source and start the scan works in a DLL loaded by a test app; it fails in the virtual channel client (RDS) DLL. I just hoped someone might know why there's a difference, because debugging isn't telling me anything other than Windows claiming that the handle is invalid.

Well, it has now come "off the shelf", however not so good news: I'm now unable to make it receive on anything other than Windows (tried iOS, macOS and Android). Sending works from any platform. I swear it was all working before. In any event, I've now made it public, here: https://github.com/DelphiWorlds/Multicaster

It came from this call in the TTwainSource.TransferImages method: rc := Owner.TwainProc(AppInfo, @Structure, DG_IMAGE, DAT_IMAGENATIVEXFER, MSG_GET, @hNative) (TwainProc is the method exported by the Twain DLL) The more pertinent question is: why does it return a valid handle in a DLL that is not loaded by WTS, and why is it apparently invalid in a DLL loaded by WTS? I figured there might be something else I need to do to ensure that it returns a valid handle in WTS.

I discovered that it is throwing an AV at this part of TTwainSource.ReadNative: DibInfo := GlobalLock(Handle); ColorTableSize := (DibNumColors(DibInfo) * SizeOf(RGBQUAD)); // <---- AV here when it calls DibNumColors, as DibInfo is nil The code is inside a DLL written for Windows Terminal Services. The same code works fine in a DLL that is just loaded via a plain application, so perhaps it has something to with WTS? If I call SysErrorMessage(GetLastError) after the GlobalLock, the message is: The handle is invalid. The value for Handle is non-zero.