Windows下向不采用WM_DROPFILES机制的第三方应用拖拽文件方案咨询

核心原因说明 #

App2未使用基于窗口消息的老式WM_DROPFILES拖拽机制，而是采用了基于COM的OLE拖放标准，该机制的交互逻辑不通过常规窗口消息传递，因此Spy++无法捕获到对应消息，这也是你之前直接发送WM_DROPFILES无效的根本原因。

可行实现方案 #

• 方案1：实现标准OLE拖放源（兼容性最优）
  1. 在App1中实现COM接口IDataObject，将待拖拽的文件路径按照Shell标准封装为CF_HDROP格式的剪贴板数据
  2. 调用Win32 API DoDragDrop触发标准拖放流程，该逻辑和资源管理器的拖放行为完全一致，只要App2能接收资源管理器的拖放，就可以正常识别该请求
• 方案2：模拟用户输入（实现成本最低）
  1. 先将待拖拽文件的路径以CF_HDROP格式写入系统剪贴板
  2. 调用Win32 API SendInput依次模拟鼠标左键按下、鼠标移动到App2可拖放区域、鼠标左键松开的全操作流程，完全复现用户手动拖拽的行为，适配几乎所有支持拖放的应用
  3. 注意高DPI场景下需要先对坐标做DPI缩放适配，避免坐标偏移导致拖放失败

权限问题处理 #

你遇到的管理员身份运行App2提示拖拽不可用但实际可运行的问题，是Windows UIPI（用户界面特权隔离）机制导致的：不同权限等级的进程之间默认会阻断拖放交互，该提示是App2自身做的权限前置检测，你的场景下刚好未触发UIPI的拦截规则因此可以正常使用。开发时建议保持App1和App2的运行权限等级一致，避免出现偶发拖放失败问题。

注意：实现OLE拖放时需要做好COM接口的引用计数管理，避免出现内存泄漏；模拟输入方案需要确保拖放时App2窗口处于前台可见状态。

内容的提问来源于stack exchange，提问作者MilesVor