|
|
1
10
在咬牙切齿和拔头发之后,我终于想出了一个可行的解决办法。在.NET及其OLE拖放支持的覆盖下,似乎有一些未记录的奇怪现象正在发生。当在.NET应用程序之间执行拖放操作时,它似乎正在尝试使用.NET远程处理,但这是否在任何地方都有文档记录?不,我想不是。 因此,我提出的解决方案涉及一个助手类来帮助在进程之间封送位图数据。首先,这是课堂。
要以支持位图的.NET和非托管收件人的方式使用该类,可以使用DataObject类进行如下的拖放操作。 要启动拖动操作:
要完成操作:
首先检查客户位图传输,因此它优先于数据对象中的常规位图。BitmapTransfer类可以放在一个共享库中,用于多个应用程序。它必须标记为可序列化,如应用程序之间的拖放所示。我在应用程序内部、应用程序之间以及从.NET应用程序到写字板之间拖放位图来测试它。 希望这能帮到你。 |
|
|
2
7
我最近遇到了这个问题,并在剪贴板中使用了自定义格式,使得互操作变得更加困难。总之,有了一点光线反射,我就能够找到原来的system.windows.forms.dataobject,然后调用getdata,像往常一样从中获取自定义项。
|
|
|
3
6
经过几个小时的挫折,我终于找到了解决这个问题的第二个办法。在旁观者的眼中,哪种解决方案最优雅。我希望迈克尔和我的解决方案都能帮助受挫的程序员,并在他们开始类似的任务时节省时间。 首先,有一件事让我印象深刻,那就是WordPad能够从盒子里接收拖放图像。因此,文件的打包可能不是问题所在,但在接收端可能发生了一些可疑的事情。 那里有鱼。事实证明,有七种类型的IDataObject在.NET框架中浮动。正如Michael指出的,OLE拖放支持试图在应用程序之间交互时使用.NET远程处理。这实际上会将System.Runtime.Remoting.Proxies.TransparentProxy放在图像应该所在的位置。显然,这不是(完全)正确的。 下面的文章给了我一些指向正确方向的建议: Windows窗体默认为System.Windows.Forms.IDataObject。但是,由于我们在这里处理的是不同的进程,所以我决定对System.Runtime.InteropServices.ComTypes.IDataObject进行一次尝试。 在dragdrop事件中,以下代码解决了问题:
两个getdata函数只共享同一个名称。一个返回对象,另一个定义为返回void,而不是将信息传递到stgmedium 外面的 参数:
最后,为了避免内存泄漏,最好调用ole函数releasestgmedium:
该功能可包括如下:
…而且这段代码似乎可以很好地处理两个应用程序之间的拖放操作(位图)。代码可以很容易地扩展到其他有效的剪贴板格式,也可能是自定义的剪贴板格式。由于没有对打包部分做任何操作,您仍然可以将图像拖放到写字板上,并且由于它接受位图格式,所以您还可以将图像从Word拖到应用程序中。 附带说明,直接从IE拖放图像甚至不会引发DragDrop事件。奇怪。 |
|
|
4
1
出于好奇,在DragDrop方法中,您是否尝试过测试是否可以从DragEventArgs中获取位图图像?不做发送者广播?我想知道PictureBox对象是否是不可序列化的,这会导致在其他应用程序域中尝试使用发件人时出现问题… |