2010-10-21 12 views
0

J'ai un composant COM C++ ATL qui affiche une fenêtre contextuelle (simple à partir de Win32, utilisant le style WS_POPUP) qui permet à l'utilisateur d'entrer des informations de recherche. Ce composant a été testé assez largement sur un formulaire VB6 (principalement pour faciliter le débogage), mais nous voulons l'utiliser avec des winforms .NET. La chose curieuse que nous avons trouvée lors de l'appel du composant à partir d'un environnement WinForms est que certaines frappes de touches ne passent plus dans notre fenêtre contextuelle. Par exemple: nous avons sous-classé une zone d'édition dans le popup pour écouter la touche ESC et fermer la fenêtre contextuelle. En VB6, cela fonctionne très bien, mais en winforms, le popup ne reçoit jamais l'événement keydown pour ESC (il le fait pour d'autres touches, comme les alphanumériques standard).Winforms dérobant des séquences de touches du composant COM?

utilisation du composant est assez trivial, mais je vais jeter un échantillon rapide ici à la tête de toutes les questions:

public partial class Form1 : Form 
{ 
    CustomPopup panel; 

    public Form1() 
    {  
     panel = new CustomPopup(); //This is the COM object 
    } 

    private void button1_Click(object sender, EventArgs e) 
    { 
     Point p = this.PointToScreen(button1.Location); 
     // Display the popup, which gives focus to a child WC_EDIT field 
     panel.ShowPopupAt(p.X, p.Y); 
    } 
} 

Comme vous pouvez le voir, pas grand-chose à elle. Donc, des idées sur quoi en Winforms mange nos frappes et comment pouvons-nous lui dire d'arrêter?

+0

AUGH !!!!! Ok, ça m'énerve vraiment, mais j'ai trouvé une solution: pendant que mes événements WM_KEYDOWN sont emportés dans l'éther, mes événements WM_KEYUP passent très bien. Dans mon cas précis, je peux m'en servir, mais ce n'est pas une solution générale à ce problème. Je ne vais pas marquer le ticket comme fermé à moins que nous puissions obtenir une sorte d'explication sur la raison pour laquelle les messages de clavier sont supprimés et comment contourner cela. (Ce sont des choses comme ça qui m'ont lentement méprisé .NET) – Toji

Répondre

0

Essayez supprimer Windows Forms traitement du message de WND (dans le contrôle/forme voler le message):

protected override void WndProc(ref Message m) 
{ 
    if (m.Msg == WM_LBUTTONDOWN || m.Msg == WM_LBUTTONUP || m.Msg == WM_LBUTTONDBLCLK 
     ) 
    { 
     return; 
    } 
    base.WndProc(ref m); 
} 
+0

J'ai déjà écrasé le WndProc à la recherche du message et il ne le reçoit jamais, donc cela ne fonctionnerait pas. Si je m'inscris en tant que IMessageFiler je le vois dans le PreFilterMessage, et il est intéressant de noter que le handle de fenêtre qu'il affiche semble être correct si je trouve la fenêtre dans Spy ++, mais cela ne correspond toujours pas à mon proc sous-classé. – Toji

+0

Si votre formulaire est en train de voler le focus et que vous n'utilisez jamais la méthode WndProc, il y a un problème. Etes-vous sûr de gérer WndProc sur le contrôle spécifique qui vole le focus? – Jeff

+0

Je ne suis pas sûr à 100%, mais étant donné que le programme se compose d'un formulaire, d'un bouton et de mon popup, il n'y a pas trop d'options à regarder. :) – Toji