MenuClick in Klasse weiterleiten
-
Danke für deine Antwort,
aber ich möchte den Klassenpointer ungern im Window hinterlegen (kann da ja nicht verifizieren, von welcher menü-Klasse der Klick kommt).
Ich möchte ihn irgendwie in dem Menü selbst hinterlegen (hmenu oder eine Struktur, an die ich über das hmenu rankomme)
bzw. über die ID (im Menuitem selbst), welche per WM_Command übermittelt wird.
-
Dann musst Du die WM_COMMAND Nachrichten eben abfangen und umleiten...
-
Um diese Umleitung machen zu können,muss ich meinen Klassenzeiger irgendwie in dem Menü hinterlegen können...doch das ist das Problem.
das abfangen selbst habe ich im ersten Post schon drin
-
gibts nix in der Menüstruktur, was ich zum abspeichern des Klassenzeigers nutzen kann?
ich muss ja auch bedenken, dass es mehrere Menüs (und damit mehrere KLassen) geben kann und ich die in der WndProc unterscheiden können muss...wie bekomme ich heraus, welches menü angeklickt wurde?
-
Ein Fenster kann nur ein Menü haben, also Speicher den Zeiger in Deinem Fenster-Objekt.
Warum bsatelst Du Dir Deine eigenen Klassen, wenn es bereits x gute Frameworks gibt?
-
ich rede nicht nur von den Menüleisten, sondern auch von Popupmenüs.
ich möchte kein Framework nehmen, da ich auf den Zielrechnerm ggf. dieses Framework nicht installieren kann...ich kompiliere nur auf der zielplattform und dann läuft es da, ohne zusätzliche Frameworkinstallationen oder Basteleien mit Umgebungsvariablen
-
Ich weiß nicht von was Du redest.
1. Wird ein Popup Menü auch von einem Fenster kontrolliert. D.h. auch hier könnte im Fenster der Zeigerauf Deine Menüklasse hinterlegt sein.
2. Braucht man weder für ATL, noch WTL noch MFC irgendwas zu installieren. Mit all diesen Frameworks kann man statisch linken und die Programm sind standalone lauffähig.
3. Ich wüsste nicht ein Framework bei dem man mit den Umgebungsvariablen "basteln" muss.
4. Gibt es Subclassing mit dem man alle Fenster-Nachrichten beliebig umbiegen und umlenken kann.
-
Für den Threadstarter.
Ein Blick in
Petzolt, Windows-Programmierung: Das Entwicklerhandbuch zur WIN32-API
erhellt den Verstand und kann beglücken.Ansonsten bin ich persönlich stark daran interessiert, ob Du wirklich mit Deinen Programmen das zugrundliegende Framework lieferst?
Im Ernst: Ohne Grundlagen (siehe Petzold) ist (Windows-)Programmierung ein Blindflug. Lesen hilft immens!
-
ich habe popupmenüs erwähnt, um zu zeigen, dass ein fenster auch mehr menüs haben kann.
in meinem kommenden Programm hat ein "Fenster" (ein ownerdraw child-control) mehrere Popupmenüs, welche ich unterscheiden muss.
ich liefere kein Framework, sondern eine klassenstruktur (fenster, controls, ...) welche sich unter beiden Betriebssystemen compilieren lassen, ohne code-Änderungen durchführen zu müssen.
Wenn man so will...ein built-in-framework, da man in dem Hauptprogramm keinen Betriebssystemrelevanten code mehr haben soll.ich dachte du meintest Multi-Platform-Frameworks wie GTK und QT, welche unter win installiert werden müssen...MFC ist ja nur Windows.
ich denke, ich werde im GTK-code auch über das Control gehen müssen, um die menü-Klicks abzufangen, um das Handling dem von windows anzugleichen.
ich dachte halt ich kann in der window-proc schon irgendwie bestimmen, von welchem HMENU der aufruf kommt...ich will mit der menü-Klasse ungern in der Wndproc des Controls rumpfuschen (Stichwort Subclassing).
-
Nein!
Ein WM_COMMAND sagtr Dir nur: Ich komme aus einem Menü, nicht aus welchem.
Ansonsten steht es Dir frei TrackPopMenu mit TPM_RETURNCMD zu verwenden.
Dann weißt Du genau was genau dieses Popup-Menü will.Warum auch?
Ob ich ein Command, über einen Menü, einen Context-Menü oder einen Button auslöse. Eigentlich passiert immer das gleiche.Deshalb ist meistens eher der Weg, dass ein Objekt das man steuern will, den Befehl erhält und sich in der UI registrier, als das die UI selbst den Befehl erhält...
Oder man hat einen zentralen Command-Prozessor.
