Teilen über

TN022: Implementierung von Standardbefehlen

Hinweis

Der folgende technische Hinweis wurde seit der ersten Aufnahme in die Onlinedokumentation nicht aktualisiert. Daher sind einige Prozeduren und Themen möglicherweise veraltet oder falsch. Für die neuesten Informationen empfiehlt es sich, nach dem interessanten Thema im Onlinedokumentationsindex zu suchen.

In diesem Hinweis werden die von MFC 2.0 bereitgestellten Standardbefehlsimplementierungen beschrieben. Lesen Sie zuerst den technischen Hinweis 21 , da sie die Mechanismen beschreibt, mit denen viele der Standardbefehle implementiert werden.

In dieser Beschreibung wird davon ausgegangen, dass sie kenntnisse der MFC-Architekturen, APIs und gängigen Programmierpraxis kennen. Dokumentierte und nicht dokumentierte "nur Implementierung"-APIs werden beschrieben. Dies ist kein Ort, um mit dem Erlernen der Features oder der Programmierung in MFC zu beginnen. Weitere allgemeine Informationen und Details zu dokumentierten APIs finden Sie unter Visual C++.

Das Problem

MFC definiert viele Standardbefehls-IDs in der Headerdatei AFXRES.H. Die Frameworkunterstützung für diese Befehle variiert. Wenn Sie wissen, wo und wie die Frameworkklassen diese Befehle behandeln, zeigen Sie nicht nur, wie das Framework intern funktioniert, sondern bietet nützliche Informationen zum Anpassen der Standardimplementierungen und vermittelt Ihnen einige Techniken für die Implementierung eigener Befehlshandler.

Inhalt dieses technischen Hinweises

Jede Befehls-ID wird in zwei Abschnitten beschrieben:

  • Der Titel: der symbolische Name der Befehls-ID (z. B. ID_FILE_SAVE) gefolgt vom Zweck des Befehls (z. B. "speichert das aktuelle Dokument") getrennt durch einen Doppelpunkt.

  • Mindestens ein Absatz, der beschreibt, welche Klassen den Befehl implementieren und was die Standardimplementierung bewirkt

Die meisten Standardbefehlsimplementierungen sind in der Nachrichtenkarte der Basisklasse des Frameworks vorverdrahtet. Es gibt einige Befehlsimplementierungen, die eine explizite Verkabelung in Ihrer abgeleiteten Klasse erfordern. Diese werden unter "Hinweis" beschrieben. Wenn Sie die richtigen Optionen in AppWizard ausgewählt haben, werden diese Standardhandler für Sie in der generierten Skelettanwendung verbunden.

Benennungskonvention

Standardbefehle folgen einer einfachen Benennungskonvention, die Sie nach Möglichkeit verwenden sollten. Die meisten Standardbefehle befinden sich an Standardplätzen in der Menüleiste einer Anwendung. Der symbolische Name des Befehls beginnt mit "ID_" gefolgt vom Standardmäßigen Popupmenünamen, gefolgt vom Namen des Menüelements. Der symbolische Name ist in Großbuchstaben mit Unterstrich. Bei Befehlen ohne Standardmenüelementnamen wird ein logischer Befehlsname beginnend mit "ID_" definiert (z. B. ID_NEXT_PANE).

Wir verwenden das Präfix "ID_", um Befehle anzugeben, die an Menüelemente, Symbolleistenschaltflächen oder andere Benutzeroberflächenobjekte gebunden sind. Befehlshandler, die "ID_"-Befehle behandeln, sollten die ON_COMMAND und ON_UPDATE_COMMAND_UI Mechanismen der MFC-Befehlsarchitektur verwenden.

Es wird empfohlen, das Standardpräfix "IDM_" für Menüelemente zu verwenden, die nicht der Befehlsarchitektur folgen und menüspezifischen Code benötigen, um sie zu aktivieren und zu deaktivieren. Natürlich sollte die Anzahl der menüspezifischen Befehle klein sein, da die MFC-Befehlsarchitektur nicht nur Befehlshandler leistungsstärker macht (da sie mit Symbolleisten arbeiten), sondern der Befehlshandlercode wiederverwendbar macht.

ID-Bereiche

Weitere Informationen zur Verwendung von ID-Bereichen in MFC finden Sie im Technischen Hinweis 20 .

MFC-Standardbefehle fallen in den Bereich von 0xE000 bis 0xEFFF. Verlassen Sie sich nicht auf die spezifischen Werte dieser IDs, da sie in zukünftigen Versionen der Bibliothek geändert werden können.

Ihre Anwendung sollte ihre Befehle im Bereich von 0x8000 bis 0xDFFF definieren.

Standardbefehls-IDs

Für jede Befehls-ID gibt es eine standardmäßige Meldungszeilen-Eingabeaufforderungszeichenfolge, die in der Datei PROMPTS zu finden ist. RC. Die Zeichenfolgen-ID für diese Menüaufforderung muss mit der Befehls-ID übereinstimmen.

  • ID_FILE_NEW Erstellt ein neues/leeres Dokument.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnFileNew implementiert diesen Befehl je nach Anzahl der Dokumentvorlagen in der Anwendung unterschiedlich. Wenn nur ein CDocTemplate vorhanden ist, wird CWinApp::OnFileNew ein neues Dokument dieses Typs sowie die richtigen Frame- und Ansichtsklassen erstellen.

    Wenn mehr als ein CDocTemplate vorhanden ist, fordert CWinApp::OnFileNew den Benutzer mit einem Dialogfeld (AFX_IDD_NEWTYPEDLG) auf, in dem der gewünschte Dokumenttyp zur Verwendung ausgewählt werden kann. Das ausgewählte CDocTemplate Objekt wird verwendet, um das Dokument zu erstellen.

    Eine allgemeine Anpassung von ID_FILE_NEW besteht darin, eine andere und grafischere Auswahl von Dokumenttypen bereitzustellen. In diesem Fall können Sie Ihre eigenen implementieren CMyApp::OnFileNew und sie in Ihrer Nachrichtenkarte anstelle von platzierenCWinApp::OnFileNew. Es ist nicht erforderlich, die Basisklassenimplementierung aufzurufen.

    Eine weitere allgemeine Anpassung von ID_FILE_NEW besteht darin, einen separaten Befehl zum Erstellen eines Dokuments jedes Typs bereitzustellen. In diesem Fall sollten Sie neue Befehls-IDs definieren, z. B. ID_FILE_NEW_CHART und ID_FILE_NEW_SHEET.

  • ID_FILE_OPEN Öffnet ein vorhandenes Dokument.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnFileOpen verfügt über eine sehr einfache Implementierung des Aufrufens CWinApp::DoPromptFileName gefolgt von CWinApp::OpenDocumentFile der Datei oder dem Pfadnamen der zu öffnenden Datei. Die CWinApp Implementierungsroutine DoPromptFileName führt das Standardmäßige Dialogfeld "FileOpen" ein und füllt es mit den Dateierweiterungen aus, die aus den aktuellen Dokumentvorlagen abgerufen wurden.

    Eine häufige Anpassung von ID_FILE_OPEN besteht darin, das Dialogfeld "FileOpen" anzupassen oder zusätzliche Dateifilter hinzuzufügen. Die empfohlene Möglichkeit zum Anpassen besteht darin, die Standardimplementierung durch Ihr eigenes FileOpen-Dialogfeld zu ersetzen und mit dem Namen der Datei oder des Pfads des Dokuments aufzurufen CWinApp::OpenDocumentFile . Es ist nicht erforderlich, die Basisklasse aufzurufen.

  • ID_FILE_CLOSE schließt das aktuell geöffnete Dokument.

    CDocument::OnFileClose Aufrufe CDocument::SaveModified , um den Benutzer aufzufordern, das Dokument zu speichern, wenn es geändert wurde, und ruft dann auf OnCloseDocument. Die gesamte schließende Logik, einschließlich der Zerstörung des Dokuments, erfolgt in der OnCloseDocument Routine.

    Hinweis

    ID_FILE_CLOSE verhält sich anders als eine WM_CLOSE Nachricht oder ein SC_CLOSE Systembefehl, der an das Dokumentrahmenfenster gesendet wird. Durch das Schließen eines Fensters wird das Dokument nur geschlossen, wenn es sich um das letzte Rahmenfenster handelt, in dem das Dokument angezeigt wird. Wenn Sie das Dokument mit ID_FILE_CLOSE schließen, wird das Dokument nicht nur geschlossen, sondern alle Rahmenfenster geschlossen, in denen das Dokument angezeigt wird.

  • ID_FILE_SAVE Speichert das aktuelle Dokument.

    Die Implementierung verwendet eine Hilfsroutine CDocument::DoSave, die sowohl für OnFileSave als auch für OnFileSaveAs verwendet wird. Wenn Sie ein Dokument speichern, das noch nicht gespeichert wurde (d. h., es hat keinen Pfadnamen, wie im Fall von FileNew), oder das aus einem schreibgeschützten Dokument gelesen wurde, fungiert die OnFileSave Logik wie der befehl ID_FILE_SAVE_AS und fordert den Benutzer auf, einen neuen Dateinamen anzugeben. Der eigentliche Prozess zum Öffnen der Datei und zum Ausführen der Speicherung erfolgt über die virtuelle Funktion OnSaveDocument.

    Es gibt zwei häufige Gründe, ID_FILE_SAVE anzupassen. Entfernen Sie für Dokumente, die nicht gespeichert werden, einfach die ID_FILE_SAVE Menüelemente und Symbolleistenschaltflächen von der Benutzeroberfläche. Stellen Sie außerdem sicher, dass Sie Ihr Dokument niemals verändern (d. h. CDocument::SetModifiedFlag nie aufrufen), und das Framework bewirkt nie, dass das Dokument gespeichert wird. Definieren Sie für Dokumente, die an einem anderen Speicherort als einer Datenträgerdatei gespeichert werden, einen neuen Befehl für diesen Vorgang.

    Bei einem COleServerDoc, ID_FILE_SAVE wird sowohl für die Dateispeicherung (für normale Dokumente) als auch für die Dateiaktualisierung (für eingebettete Dokumente) verwendet.

    Wenn Ihre Dokumentendaten in einzelnen Datenträgerdateien gespeichert werden, Sie aber die standardmäßige CDocument-Serialisierungsimplementierung nicht verwenden möchten, sollten Sie CDocument::OnSaveDocument überschreiben, statt OnFileSave.

  • ID_FILE_SAVE_AS Speichert das aktuelle Dokument unter einem anderen Dateinamen.

    Die CDocument::OnFileSaveAs Implementierung verwendet dieselbe CDocument::DoSave Hilfsroutine wie OnFileSave. Der OnFileSaveAs Befehl wird genauso wie ID_FILE_SAVE behandelt, wenn die Dokumente vor dem Speichern keinen Dateinamen hatten. COleServerDoc::OnFileSaveAs implementiert die Logik zum Speichern einer normalen Dokumentdatendatei oder zum Speichern eines Serverdokuments, das ein in eine andere Anwendung eingebettetes OLE-Objekt als separate Datei darstellt.

    Wenn Sie die Logik von ID_FILE_SAVE anpassen, möchten Sie wahrscheinlich ID_FILE_SAVE_AS auf ähnliche Weise anpassen, oder der Vorgang von "Speichern unter" gilt möglicherweise nicht für Ihr Dokument. Sie können das Menüelement aus der Menüleiste entfernen, wenn es nicht benötigt wird.

  • ID_FILE_save_COPY_AS Speichert ein aktuelles Dokument unter einem neuen Namen.

    Die COleServerDoc::OnFileSaveCopyAs Implementierung ist sehr ähnlich wie CDocument::OnFileSaveAs, mit der Ausnahme, dass das Dokumentobjekt nach dem Speichern nicht an die zugrunde liegende Datei angefügt ist. Das heißt, wenn das Speicherdokument vor dem Speichern "geändert" wurde, wird es weiterhin "geändert". Darüber hinaus hat dieser Befehl keine Auswirkungen auf den Im Dokument gespeicherten Pfadnamen oder Titel.

  • ID_FILE_UPDATE benachrichtigt den Container, ein eingebettetes Dokument zu speichern.

    Die COleServerDoc::OnUpdateDocument Implementierung benachrichtigt einfach den Container, dass die Einbettung gespeichert werden soll. Anschließend ruft der Container die entsprechenden OLE-APIs auf, um das eingebettete Objekt zu speichern.

  • ID_FILE_PAGE_SETUP Ruft einen anwendungsspezifischen Dialog zum Einrichten/Layout der Seite auf.

    Derzeit gibt es keinen Standard für dieses Dialogfeld, und das Framework hat keine Standardimplementierung dieses Befehls.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_FILE_PRINT_SETUP Das Standarddialogfeld "Drucken einrichten" aufrufen.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    Mit diesem Befehl wird das Standardmäßige Druckeinrichtungsdialogfeld aufgerufen, in dem der Benutzer die Drucker- und Druckeinstellungen für mindestens dieses Dokument oder die meisten Dokumente in dieser Anwendung anpassen kann. Sie müssen die Systemsteuerung verwenden, um die Standarddruckereinstellungen für das gesamte System zu ändern.

    CWinApp::OnFilePrintSetup verfügt über eine sehr einfache Implementierung, die ein CPrintDialog Objekt erstellt und die Implementierungsfunktion CWinApp::DoPrintDialog aufruft. Dadurch wird die Standarddruckereinrichtung der Anwendung festgelegt.

    Die allgemeine Notwendigkeit zum Anpassen dieses Befehls besteht darin, Druckereinstellungen pro Dokument zuzulassen, die beim Speichern mit dem Dokument gespeichert werden sollen. Dazu sollten Sie in Ihrer CDocument Klasse einen Nachrichtenzuordnungshandler hinzufügen, der ein CPrintDialog Objekt erstellt, es mit den entsprechenden Druckerattributen initialisiert (in der Regel hDevMode und hDevNames), die CPrintDialog::DoModalgeänderten Druckereinstellungen aufrufen und speichern. Bei einer robusten Implementierung sollten Sie sich CWinApp::DoPrintDialog zur Fehlererkennung und CWinApp::UpdatePrinterSelection für den Umgang mit sinnvollen Standardeinstellungen sowie zum Nachverfolgen systemweiter Druckeränderungen anschauen.

  • ID_FILE_PRINT Standarddruck des aktuellen Dokuments

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CView abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    Dieser Befehl startet den Druckvorgang des aktuellen Dokuments, oder genauer gesagt, initiert den Prozess, indem das Standarddruckdialogfeld aufgerufen und das Druckmodul ausgeführt wird.

    CView::OnFilePrint implementiert diesen Befehl und die Hauptdruckschleife. Es ruft das virtuelle CView::OnPreparePrinting auf, den Benutzer mit dem Druckdialog aufzufordern. Er bereitet dann den Ausgangs-DC darauf vor, zum Drucker zu gehen, ruft den Dialog Druckfortschritt (AFX_IDD_PRINTDLG) auf und sendet die StartDoc Escape an den Drucker. CView::OnFilePrint enthält auch die Hauptseiten-orientierte Druckschleife. Für jede Seite ruft es das Virtuelle auf, CView::OnPrepareDC gefolgt von einer StartPage Escape und ruft das Virtuelle CView::OnPrint für diese Seite auf. Nach Abschluss des Vorgangs wird die virtuelle CView::OnEndPrinting Datei aufgerufen, und das Dialogfeld "Druckfortschritt" wird geschlossen.

    Die MFC-Druckarchitektur ist so konzipiert, dass sie auf viele verschiedene Arten für den Druck und die Druckvorschau verwendet werden kann. Normalerweise finden Sie die verschiedenen CView überschreibbaren Funktionen für alle seitenorientierten Druckaufgaben ausreichend. Nur im Fall einer Anwendung, die den Drucker für die nicht seitenorientierte Ausgabe verwendet, sollten Sie feststellen, dass die ID_FILE_PRINT Implementierung ersetzt werden muss.

  • ID_FILE_PRINT_PREVIEW Geben Sie den Druckvorschaumodus für das aktuelle Dokument ein.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CView abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CView::OnFilePrintPreview startet den Druckvorschaumodus, indem die dokumentierte Hilfsfunktion CView::DoPrintPreviewaufgerufen wird. CView::DoPrintPreview ist das Hauptmodul für die Druckvorschauschleife, genau wie OnFilePrint das Hauptmodul für die Druckschleife.

    Der Druckvorschauprozess kann auf unterschiedliche Weise angepasst werden, indem an DoPrintPreview verschiedene Parameter übergeben werden. Bitte lesen Sie den technischen Hinweis 30, in dem einige Details der Seitenansicht und deren Anpassung erläutert werden.

  • ID_FILE_MRU_FILE1... FILE16 Ein Satz von Befehls-IDs für die Datei-MRU-Liste.

    CWinApp::OnUpdateRecentFileMenu ist ein Updatebefehls-UI-Handler, der einer der erweiterten Verwendungsmöglichkeiten des ON_UPDATE_COMMAND_UI Mechanismus ist. In Ihrer Menüressource müssen Sie nur ein einzelnes Menüelement mit id ID_FILE_MRU_FILE1 definieren. Dieses Menüelement bleibt anfänglich deaktiviert.

    Wenn die MRU-Liste wächst, werden der Liste weitere Menüelemente hinzugefügt. Die Standardimplementierung CWinApp ist standardmäßig auf den Standardgrenzwert der vier zuletzt verwendeten Dateien festgelegt. Sie können die Standardeinstellung ändern, indem Sie CWinApp::LoadStdProfileSettings mit einem größeren oder kleineren Wert aufrufen. Die MRU-Liste wird in der INI-Datei der Anwendung gespeichert. Die Liste wird in der Funktion InitInstance Ihrer Anwendung geladen, wenn Sie LoadStdProfileSettings aufrufen, und beim Beenden der Anwendung gespeichert. Der MRU-Aktualisierungsbefehls-UI-Handler konvertiert auch absolute Pfade in relative Pfade für die Anzeige im Dateimenü.

    CWinApp::OnOpenRecentFile ist der ON_COMMAND-Handler, der den tatsächlichen Befehl ausführt. Er ruft einfach den Dateinamen aus der MRU-Liste ab und ruft auf CWinApp::OpenDocumentFile, was alles tut, um die Datei zu öffnen und die MRU-Liste zu aktualisieren.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_EDIT_CLEAR Löscht die aktuelle Auswahl

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls mithilfe von CEdit::Clear bereit. Der Befehl ist deaktiviert, wenn keine aktuelle Auswahl vorhanden ist.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_CLEAR_ALL Löscht das gesamte Dokument.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden. Eine Beispielimplementierung finden Sie im MFC-Lernprogramm SCRIBBLE .

  • ID_EDIT_COPY Kopiert die aktuelle Auswahl in die Zwischenablage.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, die den aktuell ausgewählten Text mit CEdit::Copy in die Zwischenablage als CF_TEXT kopiert. Der Befehl ist deaktiviert, wenn keine aktuelle Auswahl vorhanden ist.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_CUT Schneidet die aktuelle Auswahl in die Zwischenablage.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, die den aktuell ausgewählten Text mithilfe von CEdit::Cut als CF_TEXT in die Zwischenablage schneidet. Der Befehl ist deaktiviert, wenn keine aktuelle Auswahl vorhanden ist.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_FIND Beginnt den Suchvorgang, öffnet den modelllosen Suchdialog.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, die die Implementierungshilfsfunktion OnEditFindReplace aufruft, um die vorherigen Such-/Ersetzungseinstellungen in privaten Implementierungsvariablen zu verwenden und zu speichern. Die CFindReplaceDialog Klasse wird verwendet, um den modelllosen Dialog zum Auffordern des Benutzers zu verwalten.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_PASTE Fügt den aktuellen Inhalt der Zwischenablage ein.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, der die aktuellen Daten der Zwischenablage kopiert und den ausgewählten Text mitilfe von CEdit::Paste ersetzt. Der Befehl ist deaktiviert, falls kein CF_TEXT in der Zwischenablage vorhanden ist.

    COleClientDoc stellt lediglich einen Updatebefehls-UI-Handler für diesen Befehl bereit. Wenn die Zwischenablage kein einbettbares OLE-Element/-Objekt enthält, wird der Befehl deaktiviert. Sie sind dafür verantwortlich, den Handler für den Befehl zu schreiben, der das eigentliche Einfügen ausführt. Wenn Ihre OLE-Anwendung auch andere Formate einfügen kann, sollten Sie einen eigenen Update-Befehls-UI-Handler in Ihrer Ansicht oder Ihrem Dokument bereitstellen (d.h. irgendwo zuvor COleClientDoc im Befehlsziel-Routing).

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

    Verwenden Sie COleClientItem::CanPastezum Ersetzen der standardmäßigen OLE-Implementierung .

  • ID_EDIT_PASTE_LINK Fügt einen Link aus dem aktuellen Inhalt der Zwischenablage ein.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    COleDocument stellt lediglich einen Updatebefehls-UI-Handler für diesen Befehl bereit. Wenn die Zwischenablage kein verknüpftes OLE-Element/-Objekt enthält, wird der Befehl deaktiviert. Sie sind dafür verantwortlich, den Handler für den Befehl zu schreiben, der das eigentliche Einfügen ausführt. Wenn Ihre OLE-Anwendung auch andere Formate einfügen kann, sollten Sie einen eigenen Update-Befehls-UI-Handler in Ihrer Ansicht oder Ihrem Dokument bereitstellen (d.h. irgendwo zuvor COleDocument im Befehlsziel-Routing).

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

    Verwenden Sie COleClientItem::CanPasteLinkzum Ersetzen der standardmäßigen OLE-Implementierung .

  • ID_EDIT_PASTE_SPECIAL Fügt den aktuellen Inhalt der Zwischenablage mit Optionen ein.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren. MFC stellt dieses Dialogfeld nicht bereit.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_REPEAT Wiederholt den letzten Vorgang.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, um den letzten Suchvorgang zu wiederholen. Die privaten Implementierungsvariablen für den letzten Fund werden verwendet. Der Befehl ist deaktiviert, wenn keine Suche versucht werden kann.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_REPLACE Beginnt den Ersetzungsvorgang und öffnet das Dialogfeld modellloses Ersetzen.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, die die Implementierungshilfsfunktion OnEditFindReplace aufruft, um die vorherigen Such-/Ersetzungseinstellungen in privaten Implementierungsvariablen zu verwenden und zu speichern. Die CFindReplaceDialog Klasse wird verwendet, um den modelllosen Dialog zu verwalten, der den Benutzer auffordert.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_SELECT_ALL Wählt das gesamte Dokument aus.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls bereit, der den gesamten Text im Dokument auswählt. Der Befehl ist deaktiviert, wenn kein Text zum Auswählen vorhanden ist.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_UNDO Macht den letzten Vorgang rückgängig.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    CEditView stellt eine Implementierung dieses Befehls mithilfe von CEdit::Undo bereit. Der Befehl ist deaktiviert, wenn CEdit::CanUndo FALSE zurückgegeben wird.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_EDIT_REDO Wiederholt den letzten Vorgang.

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für jede CViewabgeleitete Klasse implementieren.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_WINDOW_NEW Öffnet ein weiteres Fenster im aktiven Dokument.

    CMDIFrameWnd::OnWindowNew implementiert dieses leistungsstarke Feature mithilfe der Dokumentvorlage des aktuellen Dokuments, um einen anderen Frame zu erstellen, der eine andere Ansicht des aktuellen Dokuments enthält.

    Wie bei den meisten MDI-Menübefehlen (Multiple Document Interface, MDI) ist der Befehl deaktiviert, wenn kein aktives untergeordnetes MDI-Fenster vorhanden ist.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen. Wenn Sie einen Befehl bereitstellen möchten, der zusätzliche Ansichten oder Rahmenfenster erstellt, ist es wahrscheinlich besser, Ihren eigenen Befehl zu erfinden. Sie können den Code von CMDIFrameWnd::OnWindowNew klonen und für die spezifischen Frame- und Ansichtsklassen Ihrer Wahl anpassen.

  • ID_WINDOW_ARRANGE Ordnet Symbole am unteren Rand eines MDI-Fensters an.

    CMDIFrameWnd implementiert diesen Standard-MDI-Befehl in einer Implementierungshilfsfunktion OnMDIWindowCmd. Dieser Helfer ordnet Befehls-IDs MDI-Windows-Nachrichten zu und kann daher eine Menge Code gemeinsam nutzen.

    Wie die meisten MDI-Fenstermenübefehle ist der Befehl deaktiviert, wenn kein aktives untergeordnetes MDI-Fenster vorhanden ist.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_WINDOW_CASCADE KASKADIERT Fenster so, dass sie sich überlappen.

    CMDIFrameWnd implementiert diesen Standard-MDI-Befehl in einer Implementierungshilfsfunktion OnMDIWindowCmd. Dieser Helfer ordnet Befehls-IDs MDI-Windows-Nachrichten zu und kann daher eine Menge Code gemeinsam nutzen.

    Wie die meisten MDI-Fenstermenübefehle ist der Befehl deaktiviert, wenn kein aktives untergeordnetes MDI-Fenster vorhanden ist.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_WINDOW_TILE_Horz Kacheln Fenster horizontal.

    Dieser Befehl wird in CMDIFrameWnd genau wie ID_WINDOW_CASCADE implementiert, außer dass eine andere MDI-Windows-Nachricht für den Vorgang verwendet wird.

    Sie sollten die Standard-Kachelausrichtung für Ihre Anwendung auswählen. Sie können dies tun, indem Sie die ID für den Menüpunkt Fenster „Kachel“ entweder in ID_WINDOW_TILE_Horz oder ID_WINDOW_TILE_VERT ändern.

  • ID_WINDOW_TILE_VERT Tiles-Fenster vertikal.

    Dieser Befehl wird in CMDIFrameWnd genau wie ID_WINDOW_CASCADE implementiert, außer dass eine andere MDI-Windows-Nachricht für den Vorgang verwendet wird.

    Sie sollten die Standard-Kachelausrichtung für Ihre Anwendung auswählen. Sie können dies tun, indem Sie die ID für den Menüpunkt Fenster „Kachel“ entweder in ID_WINDOW_TILE_Horz oder ID_WINDOW_TILE_VERT ändern.

  • ID_WINDOW_SPLIT Tastaturschnittstelle zum Splitter.

    CView behandelt diesen Befehl für die CSplitterWnd Implementierung. Wenn die Ansicht Teil eines Splitterfensters ist, wird dieser Befehl an die Implementierungsfunktion CSplitterWnd::DoKeyboardSplitdelegiert. Dadurch wird der Splitter in einem Modus platziert, in dem Tastaturbenutzer ein Splitterfenster teilen oder aufheben können.

    Dieser Befehl ist deaktiviert, wenn sich die Ansicht nicht in einem Splitter befindet.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_APP_ABOUT Ruft das Dialogfeld "Info" auf.

    Es gibt keine Standardimplementierung für das Feld "Info" einer Anwendung. Die von AppWizard erstellte Standardanwendung erstellt eine benutzerdefinierte Dialogklasse für Ihre Anwendung und verwendet sie als Infofeld. AppWizard schreibt auch den trivialen Befehlshandler, der diesen Befehl behandelt und das Dialogfeld aufruft.

    Sie werden diesen Befehl fast immer implementieren.

  • ID_APP_EXIT beenden Sie die Anwendung.

    CWinApp::OnAppExit behandelt diesen Befehl, indem eine WM_CLOSE Nachricht an das Hauptfenster der Anwendung gesendet wird. Das standardmäßige Herunterfahren der Anwendung (Aufforderung für verschmutzte Dateien usw.) wird von der CFrameWnd Implementierung übernommen.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen. Es wird empfohlenCWinApp::SaveAllModified, CFrameWnd die Schließlogik zu überschreiben.

    Wenn Sie diesen Befehl implementieren, empfehlen wir, diese Befehls-ID zu verwenden.

  • ID_HELP_INDEX Listet Hilfethemen aus der .HLP-Datei auf.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnHelpIndex behandelt diesen Befehl durch einfaches Aufrufen CWinApp::WinHelp.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_HELP_USING Zeigt Hilfe zur Verwendung der Hilfe an.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnHelpUsing behandelt diesen Befehl durch einfaches Aufrufen CWinApp::WinHelp.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_CONTEXT_HELP Wechselt in den Hilfemodus SHIFT-F1.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnContextHelp bearbeitet diesen Befehl, indem Sie den Hilfsmodus-Cursor einstellen, eine Modalschleife eingeben und darauf warten, dass der Benutzer ein Fenster auswählt, um Hilfe zu erhalten. Weitere Informationen zur MFC-Hilfeimplementierung finden Sie in technischem Hinweis 28 .

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_HELP Gibt Hilfe zum aktuellen Kontext

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    CWinApp::OnHelp bearbeitet diesen Befehl, indem der richtige Hilfekontext für den aktuellen Anwendungskontext ermittelt wird. Dies behandelt einfache F1-Hilfe, Hilfe bei Meldungsfeldern und so weiter. Weitere Informationen zur MFC-Hilfeimplementierung finden Sie im Technischen Hinweis 28 .

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_DEFAULT_HELP Zeigt die Standardhilfe für den Kontext an.

    Hinweis

    Verbinden Sie dies mit der Nachrichtenkarte der von CWinApp abgeleiteten Klasse, um diese Funktionalität zu aktivieren.

    Dieser Befehl ist in der Regel zugeordnet CWinApp::OnHelpIndex.

    Ein anderer Befehlshandler kann bereitgestellt werden, wenn eine Unterscheidung zwischen der Standardhilfe und dem Hilfeindex gewünscht wird.

  • ID_NEXT_PANE Geht zum nächsten Bereich

    CView behandelt diesen Befehl für die CSplitterWnd Implementierung. Wenn die Ansicht Teil eines Splitterfensters ist, wird dieser Befehl an die Implementierungsfunktion CSplitterWnd::OnNextPaneCmddelegiert. Dadurch wird die aktive Ansicht in den nächsten Bereich im Teiler verschoben.

    Dieser Befehl ist deaktiviert, wenn sich die Ansicht nicht in einem Splitter befindet oder es keinen nächsten Bereich gibt, zu dem gewechselt werden kann.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_PREV_PANE Wechsel zum vorherigen Bereich

    CView behandelt diesen Befehl für die CSplitterWnd Implementierung. Wenn die Ansicht Teil eines Splitterfensters ist, wird dieser Befehl an die Implementierungsfunktion CSplitterWnd::OnNextPaneCmddelegiert. Dadurch wird die aktive Ansicht in den vorherigen Bereich im Teiler verschoben.

    Dieser Befehl ist deaktiviert, wenn sich die Ansicht nicht in einem Teiler befindet oder es keinen vorherigen Bereich gibt, zu dem gewechselt werden soll.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_OLE_INSERT_NEW Fügt ein neues OLE-Objekt ein

    Derzeit gibt es keine Standardimplementierung für diesen Befehl. Sie müssen dies für die abgeleitete CView Klasse implementieren, um ein neues OLE-Element/-Objekt in der aktuellen Auswahl einzufügen.

    Alle OLE-Clientanwendungen sollten diesen Befehl implementieren. AppWizard erstellt mit der OLE-Option eine Skelettimplementierung von OnInsertObject in Ihrer Ansichtsklasse, die Sie abschließen müssen.

    Eine vollständige Implementierung dieses Befehls finden Sie im Beispiel für das MFC OLE-Beispiel für OCLIENT .

  • ID_Ole_EDIT_LINKS Bearbeitet OLE-Links

    COleDocument behandelt diesen Befehl mithilfe der von MFC bereitgestellten Implementierung des Standard-OLE-Verknüpfungsdialogs. Auf die Implementierung dieses Dialogfelds wird über die COleLinksDialog Klasse zugegriffen. Wenn das aktuelle Dokument keine Verknüpfungen enthält, ist der Befehl deaktiviert.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_Ole_VERB_FIRST...LAST Ein ID-Bereich für OLE-Verben

    COleDocument verwendet diesen Befehls-ID-Bereich für die Verben, die vom aktuell ausgewählten OLE-Element/-Objekt unterstützt werden. Dies muss ein Bereich sein, da ein bestimmter OLE-Element-/Objekttyp null oder mehr benutzerdefinierte Verben unterstützen kann. Im Menü Ihrer Anwendung sollten Sie über ein Menüelement mit der ID von ID_OLE_VERB_FIRST verfügen. Wenn das Programm ausgeführt wird, wird das Menü mit der entsprechenden Menüverbbeschreibung (oder Popupmenü mit vielen Verben) aktualisiert. Die Verwaltung des OLE-Menüs erfolgt durchAfxOleSetEditMenu, durchgeführt im Update-Befehl UI-Handler für diesen Befehl.

    Es gibt keine expliziten Befehlshandler für die Behandlung jeder Befehls-ID in diesem Bereich. COleDocument::OnCmdMsg wird überschrieben, um alle Befehls-IDs in diesem Bereich aufzufangen, sie in nullbasierte Verbnummern umzuwandeln und den Server für dieses Verb zu starten (mit COleClientItem::DoVerb).

    Anpassung oder andere Verwendung dieses Befehls-ID-Bereichs wird nicht empfohlen.

  • ID_VIEW_TOOLBAR Schaltet die Symbolleiste ein und aus

    CFrameWnd bearbeitet diesen Befehl und den Update-Befehl UI-Handler, um den sichtbaren Status der Symbolleiste umzuschalten. Die Symbolleiste muss ein untergeordnetes Fenster des Rahmens mit der untergeordneten Fenster-ID von AFX_idw_TOOLBAR sein. Der Befehlshandler schaltet die Sichtbarkeit des Symbolleistenfensters tatsächlich um. CFrameWnd::RecalcLayout wird verwendet, um das Rahmenfenster mit der Symbolleiste im neuen Zustand neu zu zeichnen. Der Benutzeroberflächenhandler für den Updatebefehl überprüft das Menüelement, wenn die Symbolleiste sichtbar ist.

    Die Anpassung dieses Befehlshandlers wird nicht empfohlen. Wenn Sie zusätzliche Symbolleisten hinzufügen möchten, möchten Sie den Befehlshandler und den Ui-Handler für den Updatebefehl für diesen Befehl klonen und ändern.

  • ID_VIEW_STATUS_BAR Schaltet die Statusleiste ein und aus.

    Dieser Befehl wird CFrameWnd genauso wie die ID_VIEW_TOOLBAR implementiert, außer dass eine andere untergeordnete Fenster-ID (AFX_idw_STATUS_BAR) verwendet wird.

Nur-Aktualisierungs-Befehlshandler

Mehrere Standardbefehls-IDs werden als Indikatoren in Statusleisten verwendet. Diese verwenden den gleichen Mechanismus für die Benutzeroberflächenbehandlung mit Aktualisierungsbefehlen, um den aktuellen visuellen Zustand während der Leerlaufzeit der Anwendung anzuzeigen. Da sie vom Benutzer nicht ausgewählt werden können (d. h. Sie können keinen Statusleistenbereich verschieben), ist es nicht sinnvoll, einen ON_COMMAND Handler für diese Befehls-IDs zu verwenden.

  • ID_INDICATOR_CAPS : Feststelltastenindikator.

  • ID_INDICATOR_NUM: NUM-Sperrindikator.

  • ID_INDICATOR_SCRL: SCRL-Sperrindikator.

  • ID_INDICATOR_KANA: KANA-Sperrindikator (gilt nur für japanische Systeme).

Alle drei dieser Elemente werden in CFrameWnd::OnUpdateKeyIndicatoreinem Implementierungshilfsprogramm implementiert, das die Befehls-ID verwendet, um dem entsprechenden virtuellen Schlüssel zuzuordnen. Eine gängige Implementierung aktiviert oder deaktiviert (für Statusbereiche deaktiviert = kein Text) das CCmdUI Objekt, je nachdem, ob der entsprechende virtuelle Schlüssel momentan gesperrt ist.

Die Anpassung dieses Befehlshandlers wird nicht empfohlen.

  • ID_INDICATOR_EXT : Erweiterter Auswahl-Anzeigen-Indikator.

  • ID_INDICATOR_OVR : OVeRstrike-Indikator.

  • ID_INDICATOR_REC : RECording-Indikator.

Derzeit gibt es keine Standardimplementierung für diese Indikatoren.

Wenn Sie diese Indikatoren implementieren möchten, empfehlen wir Ihnen, diese Indikator-IDs zu verwenden und die Reihenfolge der Indikatoren in Ihrer Statusleiste beizubehalten (d. h. in dieser Reihenfolge: EXT, CAP, NUM, SCRL, OVR, REC).

Siehe auch

Technische Hinweise nach Nummer
Technische Hinweise nach Kategorie

  • Last updated on