Contents Up Previous Next

Vue d'ensemble de Document/Affichage

Classes: wxDocument, wxView, wxDocTemplate, wxDocManager, wxDocParentFrame, wxDocChildFrame, wxDocMDIParentFrame, wxDocMDIChildFrame, wxCommand, wxCommandProcessor

On retrouve le framework document/affichage dans la majorité des frameworks d'application, car il permet une simplification drastique du code nécessaire à la construction de nombreux types d'application.

L'idée est que vous pouvez basiquement modéliser votre application en termes de documents pour stocker des données et fournir des opérations sur ces données indépendament de l'interface, et des affichages pour visualiser et manipuler les données. Les documents savent comment lire et écrire à partir d'objets flux donnés, et les affichages sont responsables de récupérer l'entrée depuis des fenêtres physiques, et effectuer les manipulations sur les données du document. Si les données d'un document changent, toutes les fues doivent être mises à jour pour refléter les changements.

Le framework peut fournir plusieurs éléments de l'interface utilisateur basés sur ce modèle. Une fois que vous avez défini vos propres classes, et les relations entre elles, le framework se charge d'afficher des sélecteurs de fichiers, d'ouvir et de fermer les fichiers, de demander à l'utilisateur d'enregistrer les modifications, d'acheminer les commandes de menu vers le code (pouvant être celui par défaut) aproprié, ainsi que les fonctionnalités d'impression et d'aperçu avant impression par défaut, et le support des commandes annuler/refaire. Le framework est hautement modulaire, permettant le surclassafe et le remplacement de fonctionalité et d'objets pour réaliser plus que le comportement par défaut.

Voici l'ensemble des étapes pour la création d'une application basée sur le framework document/affichage:

  1. Définir vos propres classes de document et d'affichage, en surclassant un minimum de fonctions membres comme par exemple les fonctions d'entrée/sortie, de dessin, et d'initialisation.
  2. Définir les sous-fenêtres (telles que les fenêtres défilantes) nécessaires pour l'affichage. Vous pouvez avoir besoin d'acheminer des événements aux vues ou aux documents, par exemple, OnPaint a besoin d'être acheminé vers wxView::OnDraw.
  3. Décider quelle style d'interface vous aller utiliser : MDI Microsoft (plusieurs fenêtres de document englobées dans une frame principale), SDI (une fenêtre pour chaque document), ou "simple fenêtre" (un seul document ouvert à la fois, comme avec Windows Write).
  4. Utiliser les classes wxDocParentFrame et wxDocChildFrame apropriées. Construire une instance de wxDocParentFrame dans votre wxApp::OnInit, et un wxDocChildFrame (dans les cas autres que "simple fenêtre"), quand vous initialiser une vue. Créer les menus en utilisant les identifiants standards (tels que wxID_OPEN, wxID_PRINT).
  5. Construire une simple instance de wxDocManager au début de votre wxApp::OnInit, et ensuite autant d'instances de wxDocTemplate que nécessaire pour définir les relations entre les documents et les vues. Pour une application simple, il n'y aura qu'un seul wxDocTemplate.

Si vous voulez implémenter Annuler/Refaire, vous aurez besoin de dériver vos propres classes depuis wxCommand et utiliser wxCommandProcessor::Submit à la place d'éxécuter directement le code. Le framework va se charger d'appeler les fonctions Undo et Do apropriées, aussi longtemps que les éléments de menu wxID_UNDO et wxID_REDO seront définis dans le menu de la vue.

Voici quelques exemples de l'adaptation que vous pouvez faire à partir du comportement par défaut du framework :

Notez que pour activer les fonctionalités du framework, vous devez utiliser une partie (voir la totalité) des identifiants de commande prédéfinis dans vos menus.

Note wxPerl: Le framework document/affichage est disponible avec wxPerl. Pour l'utiliser, vous devrez placer les déclarations suivantes dans le code de votre application:

use Wx::DocView;
use Wx ':docview';   # importer les constantes (optionnel)

Vue d'ensemble de wxDocument
Vue d'ensemble de wxView
Vue d'ensemble de wxDocTemplate
Vue d'ensemble de wxDocManager
Vue d'ensemble de wxCommand
Vue d'ensemble de wxCommandProcessor
Vue d'ensemble de wxFileHistory
Identifiants wxWidgets prédéfinis


Vue d'ensemble de wxDocument

Vue d'ensemble du framework document/affichage

Classe: wxDocument

La classe wxDocument peut être utilisée pour modéliser les données basées sur des fichiers d'une application. Elle fait partie du framework document/affichage supporté par wxWidgets, et coopère avec les classes wxView, wxDocTemplate et wxDocManager.

Utiliser ce framework peut vous faire économiser une bonne quantité de programmation de routine pour l'interface utilisateur, du fait qu'une gamme de commandes de menus -- telles que ouvrir, enregistrer, enregistrer sous -- sont supportées automatiquement. Le programmeur a juste besoin de définir un ensemble minimal de classes et de fonctions membres pour que le framework puisse les appeler quand nécessaire. Les données, ainsi que les moyens pour les afficher et les éditer, sont séparés explicitement dans ce modèle, et le concept de vues mutiples à partir des mêmes données estr pris en charge..

Notez que le modèle document/affichage correspondra à de nombreux (mais pas tous) styles d'application. Par exemple, il serait trop complexe pour un simple utilitaire de conversion de fichiers, où il n'y aurait aucun appel de vue sur document, ou la capacité d'ouvrir, éditer et sauvegarder des ficheirs. Mais la majorité des applications sont probablement basées sur les documents.

Voir l'application exemple dans samples/docview.

Pour utiliser la classe abstraite wxDocument, vous devrez en dériver une nouvelle classe, et surclasser au minimum les fonctions membres SaveObject et LoadObject. SaveObject et LoadObject seront appelées par le framework que le document aura besoin d'être sauvegardé ou chargé.

Utiliser les macros DECLARE_DYNAMIC_CLASS et IMPLEMENT_DYNAMIC_CLASS afin de permettre au framework de créer des objets de document sur demande. Quand vous créez un objet wxDocTemplate lors de l'initialisation d'une application, vous devriez passer CLASSINFO(VotreClasseDocument) au constructeur de wxDocTemplate afin qu'il sache comment créer une instance dez cette classe.

Si vous ne désirez pas utiliser la méthode wxWidgets pour créer des objets document dynamiquement, vous devez surclasser wxDocTemplate::CreateDocument pour retourner une instance de la classe appropriée.


Vue d'ensemble de wxView

Vue d'ensemble du framework document/affichage

Classe: wxView

La classe wxView peut être utilisée pour modéliser les composants affichage et édition des données fichiers d'une application. Elle fait partie du framework document/affichage pris en charge par wxWidgets, et coopère avec les classes wxDocument, wxDocTemplate et wxDocManager.

Voir l'application exemple dans samples/docview.

Pour utiliser la classe abstraite wxView, vous devrez en dériver une nouvelle classe, et surclasser au minimum les fonctions membres OnCreate, OnDraw, OnUpdate et OnClose. Vous voudrez probablement répondre aux commandes de menu depuis la frame contenant la vue.

Utiliser les macros DECLARE_DYNAMIC_CLASS et IMPLEMENT_DYNAMIC_CLASS afin de permettre au framework de créer des objets d'affichage sur demande. Quand vous créez un objet wxDocTemplate lors de l'initialisation d'une application, vous devriez passer CLASSINFO(VotreClasseAffichage) au constructeur de wxDocTemplate afin qu'il sache comment créer une instance de cette classe.

Si vous ne désirez pas utiliser la méthode wxWidgets pour créer des objets affichage dynamiquement, vous devez surclasser wxDocTemplate::CreateView pour retourner une instance de la classe appropriée.


Vue d'ensemble de wxDocTemplate

Vue d'ensemble du framework document/affichage

Classe: wxDocTemplate

La classe wxDocTemplate est utilisée pour modéliser la relation entre une classe de document et une classe d'affichage. L'application crée un modèle de document pour chaque paire document/vue. La liste des modèles de document gérée par l'instance wxDocManager est utilisée pour créer les documents et les affichages. Chaque modèle de document connait les filtres de fichiers et l'extensions par défaut sont appropriés pour une combinaison document/vue, et comment créer un document ou un affichage.

Par exemple, vous pouvez créer une petite application de groffinage, qui peut charger et sauvegarder une liste des segments de ligne. Si vous avez deux affichages des données -- graphique, et liste de segments -- alors vous pouvez créer une classe de document DocGriffonage, et deux classes d'affichage (VueGriffonageGraphique et VueGriffonageListe). Vous aurez également besoin de deux modèles de document, un pour la vue graphique et un pour la vue liste. Vous pourrez passer la même classe de document et extension de fichier par défaut aux deux modèles de document, mais chacun devra se voir passer une classe d'affichage différente. Quand l'utilisateur clique sur l'élément de menu Ouvrir, le sélecteur de fichier est affiché avec une liste des filtres de fichiers possibles -- un pour chaque wxDocTemplate. Sélectionner un filtre sélectionne un wxDocTemplate, et quand un fichier est sélectionné, ce modèle de document sera utilisé pour créer le document et l'affichage.

Dans le cas où une application a un type de document et un type d'affichage, un simple modèle de document est construit, et le dialogue sera simplifié de manière appropriée.

wxDocTemplate fait partie du framework document/affichage pris en charge par wxWidgets, et coopère avec les classes wxView, wxDocument et wxDocManager.

Voir l'application exemple dans samples/docview.

Pour utiliser la classe wxDocTemplate, vous n'avez pas besoin de dériver une nouvelle classe. Il faut juste transmettre les informations au constructeur, dont CLASSINFO(VotreClasseDocument) et CLASSINFO(VotreClasseAffichage) pour permettre la création dynamique d'instance. Si vous ne voulez pas utiliser la méthode wxWidgets pour créer dynamiquement des objets document, vous devez surclasser wxDocTemplate::CreateDocument et wxDocTemplate::CreateView pour retourner les instances des classes appropriées.

NOTE: le modèle de document n'a rien à voir avec la construction de modèles (templates) C++.


Vue d'ensemble de wxDocManager

Vue d'ensemble du framework document/affichage

Classe: wxDocManager

La classe wxDocManager fait partie du framework document/affichage pris en charge par wxWidgets, et coopère avec les classes wxView, wxDocument et wxDocTemplate.

Une instance wxDocManager coordone les documents, les affichages et les modèles de document. Elle garde une liste des instances de document et de modèle, et de nombreuses fonctionnalités sont acheminées à travers cet objet, telles que les boites de dialogues de sélection de fichiers. L'application peut utiliser cette classe 'telle-quelle', ou en dériver une classe et surclasser certaines méthodes membres pour en étendre ou en changer la fonctionnalité. Créer une instance de cette classe vers le début de l'initialisation de votre application, avant la manipulation de n'importe quel document, affichage, ou modèle.

Il peut y avoir plusieurs instances de wxDocManager dans une application.

Voir l'application exemple dans samples/docview.


Vue d'ensemble de wxCommand

Vue d'ensemble du framework document/affichage

Classes: wxCommand, wxCommandProcessor

wxCommand est une classe de base pour modéliser une commande d'une application, qui est généralement une action effectuée en sélectionnant un élément de menu, en pressant un bouton d'une barre d'outils, ou par tout autre moyen fourni par l'application pour modifier les données ou l'affichage.

Plutôt que de disperser les fonctionnalités d'une application à travers des états "switch" et des fonctions, d'une façon qui peut être difficile à lire et à maintenir, la fonctionnalité d'une commande est explicitement représentée comme un objet qui peut être manipulé par un frameword ou une application. Quand un événement de l'interface utilisateur apparaît, l'application soumet une commande à un objet wxCommandProcessor pour l'éxécution et l'enregistrement.

Le framework document/affichage wxWidgets gère un historique Undo/Redo par l'utilisation d'objets wxCommand et wxCommandProcessor. Vous pourrez trouver de nombreuses applications pour wxCommand, telles que la mise en oeuvre d'une fonctionnalité de macro qui stocke, charge, et ré-exécute des commandes.

Une application peut dériver une nouvelle classe pour chaque commande, ou, plus simplement, utiliser une classe paramétrée avec un identifiant de commande de type entier ou chaîne de caractères.


Vue d'ensemble de wxCommandProcessor

Vue d'ensemble du framework document/affichage

Classes: wxCommandProcessor, wxCommand

wxCommandPRocessir est une classe qui tient un historique des instances de wxCommand, intégrant une fonctionnalité annuler/refaire. Dériver une nouvelle classe depuis celle-ci si vous avez besoin d'un comportement différent.


Vue d'ensemble de wxFileHistory

Vue d'ensemble du framework document/affichage

Classes: wxFileHistory, wxDocManager

wxFileHistory encapsule la fonctionnalité d'enregistrer les quelques derniers fichiers visités, et de permettre à l'utilisateur de rapidement charger ces fichiers en utilisant la liste ajoutée au menu Fichier.

Bien que wxFileHistory soit utilisé par wxDocManager, cette classe peut être utilisée indépendament. Vous pouvez vouloir dériver de cette classe, pour mermettre un comportement différent, telle que faire apparaître une liste déroulante de fichiers.

En appelant wxFileHistory::UseMenu(), vous pouvez associer un menu Fichier avec l'historique des fichiers. Le menu sera alors utilisé pour l'ajout des noms de fichiers qui seront placés dans l'historique. Notez que si l'historique contient déjà des noms de fichiers quand UseMenu() est appelée (par exemple, lors de l'initialisation d'une seconde fenêtre fille MDI), le menu n'est pas automatiquement initialisé avec les noms de fichiers existants dans l'historique, et vous devez donc appeller explicitement AddFilesToMenu() après UseMenu() afin que le menu soit initialisé avec la liste existante des fichiers récents (sinon, une assertion d'échec est soulevée en mode déboguage). Les noms de fichiers sont ajoutés en utilisant les identifiants allant de wxID_FILE1 à wxID_FILE9.

Afin de répondre à une commande de chargement de fichiers à partir de ces identifiants, vous devez les gérer avec un gestionnaire d'événements, par exemple:

BEGIN_EVENT_TABLE(wxDocParentFrame, wxFrame)
    EVT_MENU(wxID_EXIT, wxDocParentFrame::OnExit)
    EVT_MENU_RANGE(wxID_FILE1, wxID_FILE9, wxDocParentFrame::OnMRUFile)
END_EVENT_TABLE()

void wxDocParentFrame::OnExit(wxCommandEvent& WXUNUSED(event))
{
    Close();
}

void wxDocParentFrame::OnMRUFile(wxCommandEvent& event)
{
      wxString f(m_docManager->GetHistoryFile(event.GetId() - wxID_FILE1));
      if (!f.empty())
        (void)m_docManager->CreateDocument(f, wxDOC_SILENT);
}


Identifiants wxWidgets prédéfinis

Pour permettre la communication entre les menus de l'application et le framework document/affichage, plusieurs identifiants de commande sont prédéfinis pour vous afin que vous les utilisiez dans les menus.