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
On Sat, May 13, 2006 at 06:24:13AM +0800, qingdoa daoo wrote:
A simple test
#include "windows.h"
int APIENTRY WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmd, int show)
{
HGLOBAL hmem; LPSTR lpstr; OpenClipboard(GetDesktopWindow()); EmptyClipboard(); hmem = GlobalAlloc(GMEM_MOVEABLE, 6); lpstr = GlobalLock(hmem); lstrcpy(lpstr, "Hello"); GlobalUnlock(hmem); SetClipboardData(CF_TEXT, hmem); CloseClipboard(); return 0;}
--- Ulrich Czekalla ulrich.czekalla@utoronto.ca????:
On Fri, May 12, 2006 at 04:16:28PM +0800, qingdoa daoo wrote:
Now that you brought it up, clipboard in wine does have some limitations. e.g. when a process calls OpenClipboard(hwnd), Windows doesn't seem to care if the hwnd is owned by a thread of the calling process. A process doesn't even have to have a window in order to grab the clipboard and put something on it. It can just use the desktop window. Not so with wine.
This should work in wine as well. Do you have a test case?
/Ulrich
___________________________________________________________ ????????????????-3.5G??????20M?????? http://cn.mail.yahoo.com