Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Construction d'une application Il est bien loin le temps où réaliser un program

Construction d'une application Il est bien loin le temps où réaliser un programme consistait essentiellement à créer un fichier exécutable auquel on rajoutait un petit fichier "LISEZ.MOI.TXT" dans lequel on indiquait rapidement comment utiliser le programme. Aujourd'hui, si cette partie demeure essentielle, la construction d'une application ne se borne pas à cela et il faut penser à réaliser, en sus, un certain nombre de fonctionnalités qui assureront la prise en compte réelle de l'application par ses utilisateurs. Ces fonctionnalités annexes sont très diverses et dépendent de la fonction première de l'application. Néanmoins quelques constantes apparaissent et sont, aujourd'hui, incontournables. Il ne saurait être question de livrer une application professionnelle qui ne posséderait pas ces fonctions. Une application doit : - Posséder un module d'impression ( quelles applications n'éditent pas divers résultats ? ). Dans la mesure du possible, pour les éditions personnalisées, celles réalisées sur les postes clients, doivent être "wysiwyg" - Posséder une aide en ligne complète et ergonomique. - Pouvoir être installées facilement. Or les applications modernes mettent en œuvre, en plus de l'exécutable, divers pilotes, .DLL, fichiers d'aide etc. Cette installation ne peut donc pas être réalisée à la main et il faut prévoir une procédure automatisée prenant en compte les caractéristiques de la machine hôte. - Pouvoir être configurée. Page XV.1 15. Construction d'une application Application et modules applicatifs Installation Configuration Éditions Aide en ligne Construction d'une application 15.1 : Initialisation et paramétrage d'une application Il est de plus en plus nécessaire de disposer de dispositifs qui permettent de maintenir diverses informations indispensables au bon fonctionnement de l'application ( recueils d'information sur le système, mots de passe, personnalisation de l'application, sauvegarde d'informations recueillies, etc. ). Plusieurs dispositifs peuvent être mis en œuvre, à commencer par la simple écriture de ces informations dans un fichier externe. Mais deux sont prévus explicitement par les standards de programmation Windows : - L'utilisation de fichiers d'initialisation ( d'extension '.ini' ). - L'inscription de ces informations dans la base de registres du système.  Si l'utilisation de la base de registres est prônée aujourd'hui au détriment de l'utilisation de fichiers 'ini' ( privilégiée sous Windows 3.x ), les deux mécanismes cohabitent aujourd'hui et présentent chacun des avantages et inconvénients qu'il est intéressant de comparer. - Les fichiers 'ini' sont es fichiers externes au format texte, pouvant être édités et modifiés par le simple bloc notes de Windows. De ce fait ils sont aisément modifiables, ce qui peut sembler être un inconvénient mais se révèle être un avantage lorsque l'application est bloquée à cause d'un paramètre contenu dans le fichier. - Les fichiers 'ini' ne peuvent plus aujourd'hui avoir d'effet néfaste sur le fonctionnement du système. - La base de registres permet de stocker un grand nombre d'informations de tout types. Ce stockage se fait d'une manière "hermétique" et il faut disposer d'utilitaires spécifiques ( et d'une certaine compétence technique ) pour pouvoir modifier son contenu. - Une insertion mal contrôlée dans la base de registres peut "véroler" celle-ci et donc perturber voire bloquer le comportement de tout le système. Il semble donc qu'il faille continuer à privilégier l'utilisation des fichiers 'ini' quand ceux-ci ne doivent contenir que des informations peu sensibles ne servant qu'au bon fonctionnement de l'application. Il faut préférer l'insertion dans la base de registres dès lors qu'il s'agit de stocker des informations plus sensibles ( mots de passe, identification, numéro de licences, etc. ). 15. 11 Gestion des fichiers ".ini" : 15.111 / Généralités sur les fichiers '.ini' Windows 3.11 a généralisé l'utilisation de fichiers "texte" d'extension ".ini" qui sont des fichiers de configuration faciles à manipuler.  Le fait qu'un fichier ".ini" soit au format texte facilite sa modification. Il est en effet possible de l'éditer à l'aide de n'importe quel éditeur de texte afin de modifier manuellement un paramétrage malencontreux qui empêche le bon fonctionnement de l'application. Un fichier ".ini" est composé de sections débutant par un mot clé marqué entre crochet. Au sein d'une section, chaque ligne ( clé ) correspond à une initialisation. Page XV.2 Construction d'une application La syntaxe est la suivante : parametre=valeur d'initialisation // il n'y a pas d'espace au niveau du '='  Une ligne commençant par un ' ;' est une ligne de commentaire. Elle n'est donc pas prise en compte par l'application.  Par tradition on a tendance à créer les fichiers 'ini' dans le répertoire de Windows ( voire à utiliser les fichiers WIN.INI et SYSTEM.INI ). Si cela s'explique par le fait que c'est plus simple à réaliser lorsqu'on fait appel aux fonctions du SDK, cela entraîne une certaine anarchie au sein de ce répertoire. Il est préférable que le fichier 'ini' soit créé dans le répertoire de l'application utilisatrice. Exemple : ; lignes copiées à partir du fichier DELPHI.INI [Gallery] BaseDir=I:\DELPHI\GALLERY GalleryProjects=1 GalleryForms=1 [Experts] ExptDemo=I:\DELPHI\BIN\EXPTDEMO.DLL 15.112 / Gestion des fichiers '.ini' par la classe TIniFile : Il est possible d'accéder aux différents fichiers ".ini" via un ensemble de fonctions du SDK de Windows. Mais ces fonctions ne sont pas particulièrement aisées à manipuler et nécessitent la mises en place de tampons et l'utilisation de variables de type pointeur. C++ Builder encapsule complètement et efficacement ces fonctions en proposant une classe particulière appelée TInifile. C'est grâce à un objet créé à partir de cette classe que l'on peut créer un fichier ".ini", le lire ou le modifier ( par contre on ne peut pas le supprimer : il faut pour cela utiliser les fonctions spéciales de gestions des fichiers). La procédure à adopter est la suivante : - Déclarer une variable au type TInifile ; - Créer explicitement cette variable. - Accéder aux différentes méthodes de l'objet pour réaliser les opérations souhaitées. - Détruire l'objet, lorsque l'on en n'a plus besoin, afin de libérer la mémoire.  Bien entendu, comme on l'a déjà fait en d'autres circonstances, cet objet n'est pas accessible via l'inspecteur d'objet et tout accès ne peut être réalisé que par programmation. Page XV.3 Construction d'une application Principales méthodes : DeleteKey ( ) Supprime une clé au sein d'une section EraseSection ( ) Efface une section entière d'un fichier .INI. ReadBool ( ) ReadInteger ( ) ReadString ( ) Lit une valeur booléenne Lit une valeur entière Lit une chaîne de caractères ReadSection ( ) Lit une section entière WriteBool ( ) WriteInteger ( ) WriteString ( ) Écrit une valeur booléenne dans le fichier Écrit une valeur entière Écrit une chaîne de caractères.  On utilise les opérateurs new et delete, ainsi que le constructeur ( TIniFile ) et le destructeur de la classe pour créer et détruire un composant TIniFile.  Dans chaque fonction de lecture ou d'écriture, il faut indiquer la section concernée et le paramètre cible. Il est possible d'indiquer des valeurs par défaut.  Les méthodes Write.... écrivent un paramètre de type adéquat dans le fichier '.ini' à la section spécifiée. Si le paramètre existait déjà il est modifié, sinon il est créé. Exemple : Dans le fichier ".h" associé à la feuille indiquer : #include <inifiles.hpp> // tout en haut du fichier ...... public: // Déclarations de l'utilisateur __fastcall TForm1( TComponent* Owner ); TIniFile *ObjIni ; // Pointeur sur un objet de type TIniFile }; void __fastcall TForm1::FormCreate(TObject *Sender) { AnsiString FichierIni ; int Desc ; FichierIni = ExtractFilePath ( Application ->ExeName ); FichierIni = FichierIni + "Essai.ini" ; if ( ! FileExists( FichierIni ) ) { Desc = FileCreate( FichierIni ); // Création du fichier if ( Desc < 0 ) ShowMessage ( "Création du fichier Essai.ini impossible" ) ; else // Le fichier est créé : on l'initialise { ObjIni = new TIniFile ( FichierIni ); // Création de l'objet de type TIniFile ObjIni -> WriteString ( "A savoir", "Auteurs", "Ma compagnie à moi" ) ; Page XV.4 Construction d'une application ObjIni ->WriteString ("Options","Organisme" , "ESAT" ) ; } } else // Le fichier existe, on le lit pour initialiser l'application { ObjIni = new TIniFile ( FichierIni ); EOrganisme -> Text = ObjIni -> ReadString ( "Options", "Organisme", "ESAT"); EAuteurs -> Text = ObjIni -> ReadString ( "A savoir", "Auteurs", "" ) ; } } // Ecriture dans le fichier ini void __fastcall TForm1::Button1Click(TObject *Sender) { AnsiString FichierIni ; FichierIni = ExtractFilePath (Application ->ExeName ); FichierIni = FichierIni + "Essai.ini" ; ObjIni = new TIniFile ( FichierIni ); // Création de l'objet de type TIniFile ObjIni -> WriteString ( "A savoir", "Auteurs", EAuteurs -> Text ) ; ObjIni -> WriteString ( "Options", "Organisme", EOrganisme -> Text ) ; } 15.12 : Utilisation de la base de registres La prolifération de fichiers '.ini', et / ou l'utilisation non maîtrisée des fichiers '.ini' système ( Win.ini et System.ini en particulier ) ont provoqué de nombreux problèmes qui ont nuit à la "réputation" des ce type de fichier. Ce qui a conduit Microsoft à chercher à centraliser toutes les données de configuration dans une base spécialisée, la base de registres ( registry en anglais ).  La base de registres existait déjà sous Windows 3.1 mais n'était uploads/Litterature/ construction-d-x27-une-application.pdf