---- Reported by monkey@jpobst.com 2007-05-17 13:00:47 MST ----

Description of Problem:
The attached code generally fails on SetClipboardData, causing problems for
MWF on Windows.  It does not fail on MS.Net 2.0 runtime.  My best guess is
an interop bug.

using System;
using System.Runtime.InteropServices;

public class HelloWorld
{
	static public void Main ()
	{
		//int CF_TEXT = 1;
		int CF_UNICODETEXT = 13;
		
		Console.WriteLine ("open succeeded: {0}", OpenClipboard (IntPtr.Zero));
		Console.WriteLine ("empty succeeded: {0}", EmptyClipboard ());

		IntPtr hmem = Marshal.StringToHGlobalUni ("test");

		Console.WriteLine ("hmem: {0}", hmem.ToString ());
		Console.WriteLine ("set succeeded: {0} ({1})", SetClipboardData
((uint)CF_UNICODETEXT, hmem) != IntPtr.Zero, GetLastError ());
		Console.WriteLine ("close succeeded: {0}", CloseClipboard ());
	}
	
	[DllImport ("user32.dll")]
	private extern static IntPtr SetClipboardData (uint format, IntPtr handle);
	[DllImport ("user32.dll")]
	private extern static bool OpenClipboard (IntPtr hwnd);
	[DllImport ("user32.dll")]
	private extern static bool CloseClipboard ();
	[DllImport ("user32.dll")]
	private extern static bool EmptyClipboard ();
	[DllImport ("kernel32.dll")]
	private extern static uint GetLastError ();
}

Actual Results (win/mono 1.2.4, 1.1 and 2.0 profile):
open succeeded: True
empty succeeded: True
hmem: 19459576
set succeeded: False (0)
close succeeded: True

Expected Results (.net 2.0):
open succeeded: True
empty succeeded: True
hmem: 2142512
set succeeded: True (0)
close succeeded: True



---- Additional Comments From sebastien@ximian.com 2007-05-17 13:24:22 MST ----

The sample does work with my old Mono 1.2.2.1 under Windows XP.

C:\Temp>mono --version
Mono JIT compiler version 1.2.2.1, (C) 2002-2006 Novell, Inc and
Contributors. www.mono-project.com
        TLS:           normal
        GC:            Included Boehm (with typed GC)
        SIGSEGV:       normal
        Disabled:      none

C:\Temp>mono 81659.exe
open succeeded: True
empty succeeded: True
hmem: 12492568
set succeeded: True (0)
close succeeded: True

Note that to ensure GetLastError is meaningful you should use:
   [DllImport ("user32.dll", SetLastError=true)]
and
   Marshal.GetLastWin32Error ()

Maybe it wouldn't be 0 ?




---- Additional Comments From gert.driesen@pandora.be 2007-05-17 13:34:35 MST ----

Works fine with SVN head on Windows XP too. Haven't checked on Vista 
though.



---- Additional Comments From monkey@jpobst.com 2007-05-17 15:03:31 MST ----

My VMWare Workstation beta expired last week.  I'll try to test on
WinXP when I can to see if I can reproduce it there.

Thanks for the tips on GetLastError, unfortunately it still returns 0.
 MSDN says it should have an error for me, but it doesn't seem to.



---- Additional Comments From vargaz@gmail.com 2007-05-19 11:34:13 MST ----

Try the managed GetLastWin32Error method:

http://blogs.msdn.com/adam_nathan/archive/2003/04/25/56643.aspx




---- Additional Comments From monkey@jpobst.com 2007-05-19 13:02:35 MST ----

Yep, that's what Sebastien suggested above.  Unfortunately, it returns 0.

"Some sort of w32 error occurred: 0"



---- Additional Comments From monkey@jpobst.com 2007-06-06 10:14:52 MST ----

This works correctly on Windows XP.  Updating summary to reflect this
is a Vista-only issue.



---- Additional Comments From joncham@gmail.com 2007-07-19 21:35:44 MST ----

I doubt this is the issue (and can't test without Vista), but you
could try setting the STAThread attribute on the Main in the test
program. Again, I doubt this is it, since I'm pretty sure we call
OleInitialize to correctly set up an STA in MWF.


Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Vista (32bit)</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".