ERLEDIGT
JA
JA
ANTWORTEN
3
3
ZUGRIFFE
391
391
EMPFEHLEN
-
Tach zusammen,
Ich habe unter MFC 6.0 eine CButton-Schaltfläche, die mittels Hinterlegung (A&bwärts) auch über die Alt-Taste+b erreichbar ist.
Kurioserweise kommt das Signal EN_KILLFOCUS für ein vorher aktives CEdit-Texteingabefeld nur, wenn man den Button mit der Maus anwählt, nicht aber bei Nutzung des Tastatur-Shortcuts.
Nun bin ich platt!
Da ich eine Routine auf dem EN_KILLFOCUS hängen habe, verhält sich mein Programm nun unterschiedlich, je nachdem ob der Anwender Maus- oder Tastaturfreak ist.
Verflixt!
Weiß jemand einen Trick, aus dieser Falle zu entwischen?
Thanx
-
Das Verhalten ist klar: Wenn Du den Eingabefocus im Editfeld hast und auf eine Stelle außerhalb des Editfeldes klickst, dann verliert das Editfeld den Focus und die EN_KILLFOCUS-Nachricht wird geschickt. Wenn der Benutzer aber die Tastenkombination verwendet, dann bleibt der Focus im Editfeld -> die Nachricht wird nicht gesendet.
Ich vermute mal, daß Du in dieser Funktion eine Überprüfung des eingegebenen Textes vornehmen willst. Nach meiner Meinung ist es am einfachsten, wenn Du diese Überprüfung als eigene Funktion definierst (z.B. CheckEditInput()). Diese Funktion rufst Du dann sowohl in der Nachrichtenbehandlung für EN_KILLFOCUS als auch in der für den Button auf. Wenn nur das Editfeld und der Button im Dialog sind, dann reicht es, wenn die Überprüfungsfunktion in der Button-Routine aufgerufen wird. Je nach Ergebnis der Überprüfung setzt Du dann den Focus wieder ins Editfeld oder führst die restlichen Button-Anweisungen aus.
-
Hi jokey2,
Danke für die prompte Antwort.
Der Vorschlag wäre m.E. nur ziemlich aufwändig zu realisieren, weil ich mehrere CEdit-Felder habe.
Woher kann das On<Button>-Event wissen, auf welchem CEdit gerade der Focus hängt?
Dafür müßte ich wohl mit GetDlgItem(<IDC>) für alle CEdit-IDs einen CWnd-Pointer holen und gegen den von GetFocus() gelieferten vergleichen.
Ungünstig finde ich noch, daß der On<Button>-Event ohne Zusatzaufwand nicht weiß, ob EN_KILLFOCUS durch Mausnutzung gerade gesendet und verarbeitet wurde - meine Formatier-Routine stört es zwar zufällig nicht, aber könnte ja ohne weiteres sein.
Ich kann einfach Microsoft nicht verstehen, wieso es Sinn machen kann, einen via Maus angesteuerten Button anders zu behandeln als mittels Tastatur.
Der Anwender will doch das gleiche erreichen - nur die Wahl haben, ob ihm eben eher Maus oder Taste gefällt!
Fazit: Ich habe jetzt in meinem Programm auf ein kleines Feature verzichtet, weil mir diese aufwändige Adaption einfach zu pflegeaufwändig ist.
Trotzdem besten Dank für die Hilfestellung!
Gruß
Padd_y
-
Ist doch gar nicht aufwändig! Du holst Dir in der Button-Routine mit GetFocus den Fensterzeiger unf damit die ID des Fensters. Die ID's der Editfelder hast Du sowieso, also kannst Du schnell herausfinden, ob es eines der Editfelder ist oder nicht.
Was das Problem mit dem Doppelaufruf angeht: das ist eigentlich keines. Wenn die Überprüfung schon im EN_KILLFOCUS Handler (erfolgreich) durchgeführt wurde, macht es nichts, wenn das im Button-Handler nochmal passiert.
Noch ein Tip: Falls bei allen Editfeldern die gleiche Überprüfung stattfinden soll, kannst Du mit ON_COMMAND_RANGE einen Handler für die EN_KILLFOCUS-Nachrichten aller Editfelder anlegen statt für jedes einen eigenen.
Ähnliche Themen
-
Mit selectItems kein Funktionsaufruf über Command-Button
Von calimero im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 5Letzter Beitrag: 24.06.10, 10:11 -
Tabindex statt Tab-Taste mit Enter-Taste
Von tanjahouse im Forum Javascript & AjaxAntworten: 10Letzter Beitrag: 19.11.09, 10:06 -
HILFE ! kein Internet über firefox Ubuntu 8.10
Von SahraLE im Forum Linux & UnixAntworten: 5Letzter Beitrag: 15.01.09, 12:09 -
Kein 5.1 über optischen ausgang
Von Loveboat im Forum HardwareAntworten: 5Letzter Beitrag: 11.12.08, 00:09 -
Kein WAN über Router
Von metalgear im Forum NetzwerkeAntworten: 9Letzter Beitrag: 03.05.04, 16:11





Zitieren
Login






