MenuClick in Klasse weiterleiten

_frank_

Hallo,

ich habe mir eine Klasse gebastelt, welche ein "TWin32Control" (aktuell nur Fenster) handled.
dabei biege ich die Nachrichten aus der (nicht-klassen-WndProc [bzw static]) auf die entsprechende Klasse um.
nur wie kann ich den Pointer der Menüklasse hinterlegen?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms647591(v=vs.85).aspx
sagt mir, dass der lParam nicht verwendet wird (bzw. 0 ist), wenn ein Menü die Quelle ist.

static LRESULT CALLBACK stWinProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
	if (uMsg == WM_NCCREATE)
	{
		SetWindowLong(hWnd, GWL_USERDATA, (long)((LPCREATESTRUCT(lParam))->lpCreateParams));
	}
	TWin32Control* pWnd;
	// Get the pointer
	pWnd = (TWin32Control *)GetWindowLong(hWnd, GWL_USERDATA);
	if (pWnd)
	{
		return pWnd->MessageHandler(hWnd, uMsg, wParam,lParam);//redirect to class-message-handler
	}
	else
	{
		return DefWindowProc(hWnd, uMsg, wParam,lParam);
	}
}

so funktioniert die Weiterleitung für die Fenster-Messages...

ich dachte, ich kann hier sowas wie folgendes einfügen:

if ((uMsg == WM_COMMAND)&&(HIWORD(wParam)==0)) //Menucommand
{
//Klassenpointer des Menu ermitteln und dessen messagehandler aufrufen
}

ich möchte die Menucommands in der Menu-Klasse handlen und möglichst auf eine Separate verwaltung der Menucommands (zur klassenzuordnung) in dem TWin32Control verzichten.

_frank_

hat niemand eine idee, wie ich das realisieren kann?
vielleicht paar infos zum hintergrund...ich versuche eine Klassenstruktur aufzubauen, welche unter win32 und gtk funktioniert (für ein Programm, welches unter beiden Platformen laufen soll)

die Fensterklasse funktioniert soweit gut nur be dem Menü gibt es halt das Problem, dass die Benachrichtigung über das Fenster läuft, unter gtk lässt sich da ein eigener Messagehandler definieren.

Du kannst zusätzlichen Speicher für die Fensterklasse beim Registrieren anfordern. Dazu muss cbWndExtra in der WNDCLASS-Struktur auf einen passenden Wert (sizeof(DWORD_PTR) bspw.) gesetzt werden.

In diesem Bereich könntest du die Adresse des Menu-Handlers hinterlegen (die Adresse mit GetWindowLongPtr(hwnd, 0) ermitteln und ihn bei WM_COMMAND mit !HIWORD(wParam) && !lParam aufrufen.

Ich hoffe, ich habe deine Frage überhaupt richtig verstanden, stehe heute etwas neben mir :xmas2:

_frank_

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.

Martin Richter

Dann musst Du die WM_COMMAND Nachrichten eben abfangen und umleiten...

_frank_

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

_frank_

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?

Martin Richter

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?

_frank_

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

Martin Richter

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.

Shiba

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!

_frank_

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).

Martin Richter

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.