¡Caos del sujetapapeles!

Nota: este contenido originalmente de http://mygreenpaste.blogspot.com. Si usted es lectura él de algún otro sitio, tome por favor la época de visitar Mi goma verde, inc.. Gracias.

La AUTORIZACIÓN, así que quizás caos es un poco una palabra áspera aquí. ¡Pero el sujetapapeles me conducía recientemente las tuercas! Todo lo que intentaba hacer era copiar un poco de texto a él, y la operación fallaba. Por supuesto, como era un app ad hoc, no tenía ninguna clase de gestión de error. El app trabajó la multa justa en un sistema, pero el funcionamiento del app en otro sistema (una máquina virtual) dio lugar constantemente a falta de copiar el texto al sujetapapeles.

En última instancia, podía determinarse qué proceso evitaba que mi app pusiera datos en el sujetapapeles, pero todavía no he encontrado un workaround decente para cuando sucede el problema. No es crítico para mí, como el acto de copiar el texto al sujetapapeles es más de una sutileza que un requisito.

De todas formas, usando P/Invoke y System.Diagnostics, Encontré que vmusrvc.exe - la PC virtual “usuario virtual de la máquina mantiene” - tenía el sujetapapeles abierto. Usar los timestamps de Monitor de proceso's que perfilaba los acontecimientos (generados en 100 intervalos del ms), y el timestamp de la operación fallada de mi app, podía determinar el apilado de vmusrvc.exe:

Ningunos parámetros, user32.dll están procesando por supuesto, y la información del símbolo para vmusrvc.exe no aparece estar disponible, pero obviamente un cierto mensaje. Puedo mirar en este más un punto más último.

Para encontrar el proceso que interfería con mi trabajo del sujetapapeles, utilicé P/Invoke para llamar GetOpenClipboardWindow() y entonces GetWindowThreadProcessId(), pasando en la manija vuelta por GetOpenClipboardWindow (). Entonces, encontrar el nombre ejecutable de los procesos era apenas una cuestión de usar Módulos colección de Proceso el caso volvió pasando en el identificador de proceso recuperado por GetWindowThreadProcessId () a System.Diagnostics.Process.GetProcessById().

El código siguiente:

usar System.Runtime.InteropServices;
usar System.Diagnostics;
...
encadene los datos = “al del kajsdlkj del alkjsdl del aasdlkjasdlk”;
intento
{
    Clipboard.SetData (System.Windows.Forms.DataFormats.Text, datos);
}
retén (ee de ExternalException)
{
    LogIt (ee.ToString ());
    hWnd = GetOpenClipboardWindow de IntPtr ();
    ¡si (IntPtr.Zero! = hWnd)
    {
        pid del uint = 0;
        tid del uint = GetWindowThreadProcessId (hWnd, hacia fuera pid);
        LogIt (“proceso con el hWnd {0}, PID {1} ({1: x}), TID {2} ({2: x}),” +

                "name {3} has the clipboard", hWnd, pid, tid,
                Process.GetProcessById( (int)pid ).Modules[0].FileName );
    }
}

Resulted in the following output:

2008-03-25 00:54:45.4938864--> System.Runtime.InteropServices.ExternalException: Requested Clipboard operation did not succeed.
 at System.Windows.Forms.Clipboard.ThrowIfFailed(Int32 hr)
 at System.Windows.Forms.Clipboard.SetDataObject(Object data, Boolean copy, Int32 retryTimes, Int32 retryDelay)
 at System.Windows.Forms.Clipboard.SetData(String format, Object data)
 at Clippy.Form1.button1_Click(Object sender, EventArgs e)
2008-03-25 00:54:45.5339440--> Process with hWnd 65716 (65716), PID 1492 (5d4), TID 1496 (5d8), name C:\Program Files\Virtual Machine Additions\vmusrvc.exe has the clipboard

Interestingly, trying an alternative method of the Clipboard to set the content also failed. The Clipboard.SetDataObject() overload that takes a retryTimes and retryDelay parameter failed in the same fashion after roughly ten seconds when invoked as follows:

Clipboard.SetDataObject( data, false, 100, 100 );

I tried variations on retryTimes and retryDelay, to no avail.

Not sure what vmusrvc.exe is doing with the clipboard (probably has to do with monitoring it for host / guest VM interaction), but the act of setting the contents of the clipboard didn't fail 100% of the time in the VM. Often enough to make it extremely unreliable, though. During "normal" system usage, I was not able to cause a failure when running the app on a non-virtual (actual?) system.

Written by «/\/\Ø|ö±ò\/»®©. Read more great feeds at is source WEBSITE
no comments.
Read more articles on P/Invoke and GetOpenClipboardWindow and System.Diagnostics and Clipboard and GetWindowThreadProcessId and Process Monitor and c# and processes and Virtual Machine and otherSoftware and Virtual PC.

• [+] Digg: Feature this article
• [+] Del.icio.us: Bookmark this article
• [+] Furl: Bookmark this article