Wohin mit den Nachrichtenbehandlungen für Menüs
-
Hallo!
Vorweg: Ich beziehe mich jetzt auf Dialogfeld basierende Applikationen. Gilt aber auch für andere.
Wenn man unter Visual Studio ein Menü und dann einen Ergeignishandler vom Typ Command für das jeweilige Menüelement erstellt (mit Hilfe der Assistenten), wird die private Methode, die später den Code beinhaltet in die Applikationsklasse geschrieben. Warum?
Warum wird der Code nicht direkt in die Dialogfeldklasse geschrieben?
Stehe jetzt nämlich mal wieder vor dem Problem: Wo "gehört" der Code hin?Ich schreibe mir den Code lieber selber in die Dialogfeldklasse, da das Menü zu *diesem* Dialogfeld gehört. Ist davon grundsätzlich abzuraten?
P.S.: Ich hoffe, dass ich mein Problem halbwegs verständlich formulieren konnte.
-
Bei einer Dialoganwendung würde ich auch den jeweiligen Dialog nehmen.
Ich habe eine SDI, da finde ich den MainFrame ganz gut.
-
estartu schrieb:
Bei einer Dialoganwendung würde ich auch den jeweiligen Dialog nehmen.
Ich habe eine SDI, da finde ich den MainFrame ganz gut.Also kann man das nicht unbedingt verallgemeinern, sondern kann es ruhig individuell machen?
-
Also ich finde CMainRame einen äußert ungeeigneten Punkt.
Der Menühandler kommt dahin wo auch die Behandlung am effektivsten ist:
Status-Einstellungen für die Applikation-> Nach CWinApp!
View Aktionen -> in den View
Nur dann wenn die Darstelung und interkationen zwischen Views gefordert ist -> in den Frame
Alles was mit den Daten zu tun hat -> in das Document.Es macht doch keinen Sinn einen Menü Befehl der sich auf die daten bezieht im Frame zu behandeln, wenn ich mir dort erst mühsamst das Active Document besorgen muss.
Für was gibt es denn das Command Routing?
-
Ich finde den Frame trotzdem gut, da ich an der Stelle an das gerade offene Dokument bzw. die Basisklasse aller Docs weitergebe.
Im Frame werden nur die ersten Fehler abgefangen.Ist wirklich fallabhängig, denke ich.
-
Aber warum?
Wenn doch sowieso über das aktive Dokument geroutet wird, warum sollte ich das Frame einschalten, dass weiter hinten in der Routing Kette liegt.
Routing Folge:
Active View
Active Document
Document template
Frame
(Parent Frame bei MDI)
ApplicationDiese Floge würde ich immer nutzen. Ich würde niemals einen Handler im Frame einbauen, der ja schon im Document behandelt werden könnte.
Zudem warum sollte mein Frame was über das Design des Views oder der Dokumente wissen?
Warum sollte mein Dokument etwas übr Frame oder View wissen?
Nur das View kennt das Dokument!Mehr Bindungen würde ich vermeiden!
-
Martin Richter schrieb:
Aber warum?
Wenn doch sowieso über das aktive Dokument geroutet wird, warum sollte ich das Frame einschalten, dass weiter hinten in der Routing Kette liegt.
Gleiches würde doch auch für dialogbasierende Applikationen gelten, richtig?
CWinApp->CDialog.
Also wäre es sinniger auch hier die ON_COMMAND Nachrichten zu bearbeiten.
-
1. Es gibt in Dialogen kein Command Routing
2. Das Standardverhalten sieht also immer die Behandlung im Dialog vor.
-
Martin Richter schrieb:
1. Es gibt in Dialogen kein Command Routing
2. Das Standardverhalten sieht also immer die Behandlung im Dialog vor.Wenn ich das jetzt richtig verstehe, werden die ON_COMMAND Nachrichten direkt "an" den Dialog gesand. Hmm, warum schreibt der MFC Assistent denn dann alles in Applikationsklasse?
-
Hast Du ein Menü erzeugt? VC6?
Die Ressource gehört zu einem bestimmten Object. In Deinem Fall eben der Applikation.Das ist der einer der Gründe warum ich den Assistenten und den Classwizard nicht mag! Der Classenassi in VS2005 ist da weitaus flexibler.
-
Martin Richter schrieb:
Hast Du ein Menü erzeugt? VC6?
Ja.
Martin Richter schrieb:
Der Classenassi in VS2005 ist da weitaus flexibler.
Ja, der fragt wo's hin soll.
-
HaJo. schrieb:
Martin Richter schrieb:
Hast Du ein Menü erzeugt? VC6?
Ja.
Ich stehe zu meiner Meinung: "VC6 verschrotten"
