Jump to content

Dave Nottage

Members
 View Profile  See their activity

  • Content Count

    1296

  • Joined

  • Last visited

  • Days Won

    29

Posts posted by Dave Nottage

  2. Posted

    17 minutes ago, rvk said:

    Are your connecting client, the used mstsc.exe and RDP-session (including your app) ALL 64 bit?

    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?

     

    21 minutes ago, rvk said:

    Did you check the numerical value of hNative (i.e. not being 0)?

    Yes, it's non-zero.

  3. Posted

    15 minutes ago, rvk said:

    So, the drivers are not loaded on the server itself?

    Not on the remote machine no, since it does not have the scanner connected; the local machine does, where the RDS DLL resides.

     

    16 minutes ago, rvk said:

    It seems the value is not checked for success there ( if rc <> TWRC_SUCCESS then ... should give error )

    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.

  5. Posted

    4 hours ago, rvk said:

    is the scanner-software (and 64bit driver) directly installed on the WTS machine?

    That is correct. 

     

    4 hours ago, rvk said:

    Not sure what you mean by this? In Windows Terminal Services (now called Remote Desktop Services, RDS) you also just run plain applications, don't you?

    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.

  6. Posted

    On 6/27/2019 at 8:53 PM, Dave Nottage said:

    My work has been "sitting on a shelf" waiting for funding for the project(s) it may be used in, but I could turn it into some building blocks for anyone who's interested.

    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

     

     

  7. Posted

    31 minutes ago, David Heffernan said:

    You need to work out where Handle came from

    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)

    32 minutes ago, David Heffernan said:

    why it is not valid.

    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.

     

     

  8. Posted

    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.

     

  9. Posted

    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:
    image.thumb.png.454b631f07f1ed62440f593d0c8d737c.png
     

    Any ideas of what I've done wrong, and how to remedy it?

  11. Posted

    Delphi Rio 10.3.1, VCL.

     

    I was having problems with refactored code based on the original. I went back to the very original code and managed to make it work, so something must have gone awry in the refactor.

     

    Next time it is refactored there'll be incremental testing 🙂

     

    Next issue is: when it is used in a DLL, the app locks up after the scan has completed.

  13. Posted

    I managed to make UDP multicast work to my satisfaction (with both IPv4 and IPv6) with Indy a while ago.. had to jump through a bunch of hoops to make it happen.

     

    My work has been "sitting on a shelf" waiting for funding for the project(s) it may be used in, but I could turn it into some building blocks for anyone who's interested.

     

    One of the things I had to overcome was the lack of multiple bindings in TIdIPMCastServer - a pretty basic omission. Others were: local address changes (because of one or more networks being unavailable etc), dealing with IPv6 only networks (a must for iOS), and discovering local addresses on Android (which Indy does not do yet, unless it has changed recently)

     

    I've tried a number of network libraries including ICS, but Indy is still the least painful to work with. Much kudos to Remy.

     

     

  15. Posted

    On 6/20/2019 at 1:53 AM, ertank said:

    Here is a screen shot from options page

    Which means it cannot find a matching certificate for the provisioning profile. Please ensure that the provisioning profile you are using actually *has* the iOS Distribution certificate assigned to it.  To do this, go to:

     

    https://developer.apple.com/account/

     

    Log in, go to Certificates, IDs and Profiles, select Profiles section, and select the profile for rexpressmanager (make sure it's actually an App Store profile), and check which certificate is assigned to it (bottom left of the info). If it's not an App Store profile, you'll need to create one.

     

  16. Posted

    22 hours ago, ertank said:

    However, it cannot be deployed using Application Store configuration

    I should have also asked what you mean by this, i.e. is there an error thrown in the IDE? If so, please give all the details. If not, at what stage is it a problem? Using Application Loader?

  17. Posted

    2 hours ago, ertank said:

    As far as I can tell. MacOS already have deployment certificate installed

    Please describe what gives you the impression that one is installed. One way is to use the Keychain application on the Mac, select login in the keychains list, and My Certificates in the category list. There should be at least one iPhone Distribution certificate. Check the expiry date that it has not expired.

     

  18. Posted

    10 hours ago, rvk said:

    What/which scannerdriver did you try/use?

    It works for Win32, and reports the following sources:

     

    Brother DS-620

    WIA-Apple iPhone (my iPhone)

    WIA-Galaxy Tab Active2 (an Android device connected to the computer)

     

    For Win64, it errors, as per my original post

     

  19. Posted

    On 6/15/2019 at 6:38 AM, stijnsanders said:

    Even so, is TWINDSM.DLL you're using also 64-bits?

    Yes, TWAINDSM.DLL is 64 bits.

     

    On 6/15/2019 at 6:38 AM, stijnsanders said:

    (Is this the place to get current ones?)

    From here:  https://github.com/twain/twain-dsm/tree/master/Releases/dsm_020402/windows/64

     

    Though I've now tried those from the link you gave, with the same result.

     

    In case anyone asks: I have already also verified that the correct DLL is being loaded by using GetModuleName for the handle returned.

     

     

  20. Posted

    16 hours ago, David Heffernan said:

    You followed the instructions for 64 bit compilers, made the necessary change to the code outlined on the page you linked, obtained 64 bit drivers etc?

    Yes, since as I said, it loads the driver OK. The problem comes after that

×