从Delphi应用发送WM_COPY.转到Windows 7中的另一个进程 [英] Sending WM_COPY from a Delphi app. to another process in Windows 7

问题描述

我有一个Delphi(BDS 2006)应用程序，该应用程序将击键发送到QuickBooks记帐软件以遍历QuickBooks表单(发票)，将文本从当前编辑控件复制到Windows剪贴板(以收集数据)，并根据收集数据，最后通过发送击键将结果写在表单上.

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.

此应用程序已经开发了多年，它使用了广泛的Windows API技术(至少对我而言)来识别前台窗口，聚焦窗口等，并且被全世界数十个用户使用...我仅告诉您它可以在很多系统上运行的证据.

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.

但不是全部.最近，我在Windows 7系统上收到了大量的故障报告(QuickBooks的版本似乎无关紧要).发送给已报告问题的客户的调试版本表明它没有将任何内容复制到剪贴板上-尽管它似乎仍然可以执行其他所有操作(发送击键以遍历表单，并击键以粘贴到计算结果中) ...不幸的是，由于没有收集到任何数据，现在它始终为零.)

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

这是我用于将WM_COPY消息发送到QuickBooks中的编辑控制窗口的代码. (在XP或Windows 7系统上，我们都无法使此代码在这里失败-但它不适用于多个用户.)

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

注释/问题:

• 所有其他击键都是通过SendInput发送的，它们可以正常工作.我相信我们出于速度原因开始使用SendMessageTimeout(WM_COPY)而不是发送Ctrl-C作为击键-它使我们能够在返回时立即访问剪贴板，而不是等待未知/不确定的时间来让Ctrl-C由QuickBooks处理.

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

我相信我们已经要求用户在我们的应用程序上尝试RunAs ... Administrator，但这没有任何效果(我必须验证已完成).

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

我想知道问题是否可能是由于UAC冲突引起的?我们的应用程序当前未经过数字签名，不使用任何清单.我一直在阅读有关添加带有UIAccess = True的清单的信息.但是，如果我们的应用程序已经可以将击键发送到QuickBooks而没有问题，那么设置UIAccess = True是否对成功发送SendMessageTimeout()有任何影响?我需要使用数字证书吗?使UIAccess设置生效?

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?

如果没有数字签名&则SendMessage无法工作清单中的UIAccess，是否有可能我们退回到发送Ctrl-C作为击键? (我不这么认为；当然，Microsoft不会允许围绕安全性概念的最终尝试.)

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

推荐答案

这可能与用户界面权限隔离"(UIPI)而不是UAC有关.检查每个过程的完整性级别.较低完整性的进程不允许将窗口消息发送到较高完整性的进程，除非较高完整性的进程通过调用ChangeWindowMessageFilter/Ex()明确允许它.

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

这篇关于从Delphi应用发送WM_COPY.转到Windows 7中的另一个进程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！