Verständnisfrage zum Benutzen von SetClipboardData

Hoi,
ich habe gerade mal versucht, mich in der MSDN schlau darüber zu machen,
aber so ganz schein ich das nicht zu verstehen..

1. Was genau ist "HANDLE hMem" bei SetClipboardData?
Muss das der Rückgabewert von Global-/LocalAlloc sein?
Oder funktioniert auch HeapAlloc oder sogar einfach nur Pointer zu einem String?

2. Was bedeutet "If the application specifies a NULL window handle when opening the clipboard, EmptyClipboard succeeds but sets the clipboard owner to NULL. Note that this causes SetClipboardData to fail."?

3. Muss man nach SetClipboardData Global-/LocalFree bzw. HeapFree aufrufen, um das, was man davor alloziiert hat, wieder freizugeben, oder ist das die Aufgabe von EmptyClipboard?
Oder werden innerhalb von SetClipboardData die Daten kopiert, sodass man dann sozusagen das, was man vorher alloziiert hat, 2x hat und daher sein eigenes Handle selber und das übergreifende Handle via EmptyClipboard freigeben muss?

Vielen Dank

Martin Richter

der_ratlose schrieb:

1. Was genau ist "HANDLE hMem" bei SetClipboardData?
Muss das der Rückgabewert von Global-/LocalAlloc sein?
Oder funktioniert auch HeapAlloc oder sogar einfach nur Pointer zu einem String?

Steht hier:
http://msdn.microsoft.com/en-us/library/ms649014(VS.85).aspx
A memory object that is to be placed on the clipboard should be allocated by using the GlobalAlloc function with the GMEM_MOVEABLE flag.

Steht auch in der Beschreibung von SetClipboardData!

2. Was bedeutet "If the application specifies a NULL window handle when opening the clipboard, EmptyClipboard succeeds but sets the clipboard owner to NULL. Note that this causes SetClipboardData to fail."?

D.h.: Willst Du einen Inhalt setzen, musst Du auch ein hWnd bei OpenClipboard angeben.
Durch das hWnd wird der Owner des Clipboards bestimmt (vermutlich auch der Prozess). Ohne hWnd kannst Du das Clipboard löschen, aber nciht füllen.

3. Muss man nach SetClipboardData Global-/LocalFree bzw. HeapFree aufrufen, um das, was man davor alloziiert hat, wieder freizugeben, oder ist das die Aufgabe von EmptyClipboard?
Oder werden innerhalb von SetClipboardData die Daten kopiert, sodass man dann sozusagen das, was man vorher alloziiert hat, 2x hat und daher sein eigenes Handle selber und das übergreifende Handle via EmptyClipboard freigeben muss?

Steht auch in der MSDN:
http://msdn.microsoft.com/en-us/library/ms649051(VS.85).aspx
If SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.

Zu 1./3.:
Funktioniert anscheinend aber auch mit VirtualAlloc..
Ebenso klappt noch alles, wenn man direkt nach SetClipboardData den Speicher wieder freigibt

Zu 2.:
Hm, scheint dennoch zu funktionieren..

Martin Richter

Ich würde Dir nicht raten, gegen diese Regeln zu verstoßen.
Glaubst Du, dass diese Sätze alle aus Spaß in der MSDN stehen?

Hast Du es auch über Prozessgrenzen versucht, und nicht nur mit CF_TEXT? D.h. auch eigene Formate?

CF_TEXT ist eine Sonderform, die auf einem Rechner ab W2K automatisch in CF_UNICODETEXT umgewandelt wird...