How about doing something in explorer. We already launch an instance of explorer as systray listener for the first Win32 app. We could make explorer also act as a clipboard server. If that can be done, we no longer rely on any message loop in the process doing clipboard operations.
This case *is* important. for example I believe this is why copy/paste doesn't work in MSVC6 under wine. We can also make more improvements on the clipboard implementation once the new framework is done.
--- Ulrich Czekalla ulrich.czekalla@utoronto.ca wrote:
Yes this case is problematic.
Now that the desktop window is owned by the explorer process OpenClipboard(GetDesktopWindow()) won't work. The selection owner will become the explorer process but the data will live in the current process. The result will be that no data will be available to external processes. The code currently depends on the window belonging to the current process. Removing this requirement may require moving the clipboard data to the wineserver. I have to think about this some more. Either way I'm not sure this case is that important.
One limitation is that we must have a message loop running to handle the X selection events otherwise other processes won't have access to our clipboard data. So even if I fix the issue with the wrong process becoming the selection owner your simple app won't work :-( I don't think it's a major concern though because most windows app have a message loop.
/Ulrich
___________________________________________________________ 抢注雅虎免费邮箱-3.5G容量，20M附件！ http://cn.mail.yahoo.com