Question

I have a Delphi (BDS 2006) application which sends keystrokes to QuickBooks accounting software to traverse QuickBooks forms (invoices), copy text from the current edit control to the Windows clipboard (to gather data), do some calculations based on the gathered data, and finally write results on the form by sending keystrokes.

This application has been developed over a number of years, uses extensive (for me at least) Windows API techniques to identify the foreground window, focused window, etc., and is used by dozens of users worldwide…which I only tell you as evidence that it works on a lot of systems.

But not all. Lately I’m getting a lot of reports of failures, on Windows 7 systems (the version of QuickBooks doesn’t seem to matter). Debugging versions sent to the customers who’ve reported problems show that it is not copying anything to the clipboard–though it still seems to be able to do everything else (send keystrokes to traverse the form, and keystrokes to paste in the calculation result…which unfortunately, is now always zero because no data was gathered.)

Here’s the code I use to send a WM_COPY message to the edit control window in QuickBooks. (We can’t get this code to fail here, on either XP or Windows 7 systems–but it doesn’t work for several users.)

var
  iResult : DWORD;
begin
  ...
      //Edit control has the focus on the QB form, so try to copy its contents
  if SendMessageTimeout(Wnd, WM_COPY, 0, 0,
      SMTO_ABORTIFHUNG or SMTO_NORMAL,
      2000,
      iResult) = 0 then begin                 //0 = Failed or timed out

        //NOTE:  Users DO NOT get the following message--the 
        //SendMessageTimeout() simply returns without error, as if the 
        //WM_COPY is being sent correctly.

    ShowMessage('SendMessageTimeout FAILED');
    Abort;    
  end;

            //At this point, the clipboard has nothing on it, on users'
            //machines where it fails to work.
  ...   
end;

Not wanting to wear out the patience of the end users to whom we’re sending debug versions, I’m looking for ideas before we send out anything else for them to try/test…

Notes/Questions:

• All other keystrokes are sent via SendInput, and they work fine. I believe we began using SendMessageTimeout(WM_COPY) instead of sending Ctrl-C as a keystroke for speed reasons–it allowed us to immediately access the clipboard on return, instead of waiting an unknown/indefinite amout of time for the Ctrl-C to be processed by QuickBooks.

• I believe we’ve asked users to try RunAs…Administrator on our application, but that had no effect (I’ll have to verify that’s been done).

• I’m wondering if the problem could be due to UAC conflicts? Our application currently is not digitally signed and uses no manifest. I’ve been reading about adding a manifest with UIAccess=True in it. But if our application can already send keystrokes to QuickBooks without problems, would setting UIAccess=True have any effect on allowing the SendMessageTimeout() to succeed? And will I need to use a digital cert. to get the UIAccess setting to have any effect?

• If SendMessage won’t work without digitally signing & UIAccess in the manifest, is it possible we could fall back to sending Ctrl-C as a keystroke? (I wouldn’t think so; surely Microsoft wouldn’t allow that end-run around a security concept.)

I’d appreciate any comments to straighten out my thinking…

Answer 1

This might be related to “User Interface Privilege Isolation” (UIPI) instead of UAC. Check the integrity level of each process. A lower-integrity process is not allowed to send window messages to a higher-integrity process, unless the higher-integrity process explicitly allows it by calling ChangeWindowMessageFilter/Ex().