Chaos de presse-papiers !

Note : ce contenu à l'origine de http://mygreenpaste.blogspot.com. Si vous êtes lecture il d'un autre emplacement, prenez svp le temps de visiter Ma pâte verte, inc.. Merci.

L'OK, ainsi peut-être chaos est un peu un mot dur ici. Mais le presse-papiers me conduisait récemment des écrous ! Tout que j'essayais de faire était de copier un certain texte à lui, et l'opération échouait. Naturellement, car c'était un APP ad hoc, je n'ai eu aucun genre de gestion d'erreur. L'APP a fonctionné l'amende juste sur un système, mais courir l'APP sur un autre système (une machine virtuelle) a uniformément eu comme conséquence le manque de copier le texte au presse-papiers.

Finalement, je pouvais déterminer quel processus empêchait mon APP de mettre des données dans le presse-papiers, mais je n'ai pas encore trouvé un workaround décent pour quand le problème se produit. Il n'est pas critique pour moi, comme acte de copier le texte au presse-papiers est plus d'une finesse qu'une condition.

Quoi qu'il en soit, en utilisant P/Invoke et System.Diagnostics, J'ai constaté que vmusrvc.exe - le PC virtuel « utilisateur virtuel de machine entretient » - a eu le presse-papiers ouvert. Employer les horodateurs de Moniteur de processus's profilant des événements (produits à 100 intervalles de mme.), et l'horodateur de l'opération échouée de mon APP, je pouvais déterminer la pile de vmusrvc.exe :

Paramètre, naturellement, et l'information de symbole pour vmusrvc.exe ne semble pas être disponible, mais évidemment user32.dll ne traite pas un certain message. Je peux regarder dans ce plus un point postérieur.

Pour trouver le processus qui interférait mon travail de presse-papiers, j'avais l'habitude P/Invoke pour appeler GetOpenClipboardWindow() et puis GetWindowThreadProcessId(), passant dans la poignée retournée par GetOpenClipboardWindow (). Puis, la conclusion du nom exécutable des processus était simplement une question d'employer Modules collection de Processus l'exemple est retourné par le dépassement dans l'identification de processus recherchée par GetWindowThreadProcessId () à System.Diagnostics.Process.GetProcessById().

Le code suivant :

employer System.Runtime.InteropServices ;
employer System.Diagnostics ;
...
ficelez les données = « Al de kajsdlkj d'alkjsdl d'aasdlkjasdlk » ;
essai
{
    Clipboard.SetData (System.Windows.Forms.DataFormats.Text, données) ;
}
crochet (ee d'ExternalException)
{
    LogIt (ee.ToString ()) ;
    hWnd = GetOpenClipboardWindow d'IntPtr () ;
    si (IntPtr.Zero ! = hWnd)
    {
        pid d'uint = 0 ;
        tid d'uint = GetWindowThreadProcessId (hWnd, dehors pid) ;
        LogIt (« processus avec 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