Quand, je suis en manque d'inspiration pour un projet à faire en Gambas, je reprends un de mes vieux programmes et là je pleure (je ne suis pas professionnel de la programmation) car je mesure le chemin parcouru.
Et celui qui reste pour avancer est encore bien long (tant mieux).
Sans avoir, à tout réécrire, réorganiser son ancien projet en un nouveau, est un processus intéressant, permettant de mesurer ses propres progrès et continuer à s'améliorer.
Je vous donne, mes propres pistes empruntées :
Pour illustrer mon propos, voici une ossature de projet vide qui ne constitue pas, en aucune manière, un modèle, mais simplement, un chemin de réflexion que j'ai emprunté.
Il s'agit d'un projet traduisible avec un splash screen simple, modifiable, un menu réduit à alimenter en fonction de ses besoins.
Dans l'IDE :
- Des répertoires pour Modules, Formulaires, Tâches, Classes, et autres objets dont on pourrait avoir besoin.
- Des répertoires pour chaque type de données nécessaires au bon fonctionnement de notre application.
CObjetNecessaire, tous les objets nécessaires à votre application seront regroupés, là.
Rappelons qu'un objet est simplement une instance d'une classe.
FAide, à construire selon ses envies.
FChoixPolice, pour choisir et modifier la police employée au niveau des formulaires.
FSplash, le splash screen, pour faire pro.
FMain, le formulaire principal de votre application, à développer.
- Un module de début qui lance le programme et le termine.
- Un module par type d'action : sons, settings, langues, variables globales au projet, connexion à une base de données, éventuelle.
Genre : MSon, MSettings, MVar, MConn, ...
Un répertoire, enfin pour les TASKS dont nous pourrions avoir besoin :
CTaskNecessaire, c'est un fichier classe mais on le met à part pour bien le différencier.
Car tout est, ici dans la présentation et l'organisation de notre projet, en résumé dans sa structuration
La structuration de notre projet doit nous permettre de bien structurer notre pensée et par là même notre réflexion par rapport au besoin que nous voulons exprimer dans notre application.
Un exemple, pour illustrer cette nécessité de structure,
Quel est l'intérêt :
Nous regroupons les variables dans un seul endroit. Deux façons de procéder peuvent s'entrechoquer :
- regrouper les variables par provenance
- regrouper les variables par type
- ou même une troisième, par provenance et puis par type
Au début on aura tendance à les regrouper par provenance puis très vite on les regroupera par type, en s'apercevant que c'est plus intéressant, car leur type est plus important que leur provenance.
Petit rappel, un module est une région particulière, qui est Static et Public, ce qui protège vos variables car elles ne sont pas accessibles autrement que par des appels de votre application que vous aurez programmés.(voir les différences entre static et dynamic, sur le site.)
Il est vrai qu'il faudra ajouter "MVar." devant le nom de la variable quand il faudra l'appeler de n'importe où dans le projet.
Un mot sur cette procédure particulière :
-2-L'application de la langue sélectionnée par l'utilisateur.
Bien suivre, les mentions entourées d'étoiles, elles expliquent que le changement de langue ne peut se faire que par le redémarrage de l'application.
Quand, on effectue ses tests dans l'IDE, la première ligne doit être dé-commentée et la suivante commentée.
Quand on veut effectuer la compilation de son projet, au contraire on commente la première et dé-commente la seconde.
Cette ligne :
fonctionne, aussi, mais ne quitte pas proprement l'application, et il reste plein de choses de l'application, en mémoire.
dont nous aurons préalablement préparées les traductions.
Configuration de la langue enregistrée et du menu :
Le menu Langue sélectionné :
Application de la langue choisie :
Une image du menu permettant de sélectionner la langue désirée :
Le module de démarrage, MDebut en deux procédures, ouverture et fermeture.
Ouverture :
Fermeture :
Bien sûr un module de démarrage et de fin n'est pas obligatoire, mais il oblige à bien penser ses initialisations et instanciations et lors de la clôture, il rassemble les objets dont il faut s'occuper pour réaliser une fermeture propre de l'application.
Le Splash Screen, n'est qu'une cerise sur le gâteau, un plaisir supplémentaire qui ne devrait se justifier que dans le cas où "beaucoup" de choses devraient être lancées avant que l'application ne démarre, pour faire patienter l'utilisateur. Ici, il ne s'agit que d'une "tricherie".
Déclarations minimales :
L'ouverture du formulaire :
Le travail du Timer :
La fermeture du formulaire :
Cette ossature de projet vide ne constitue pas, encore une fois, un modèle, mais simplement, un chemin de réflexion que j'ai emprunté et tenais à partager.
Endroit de téléchargement sur la forge de ce projet : https://gambas-fr.org/code-279-ossaturedeprojet.html
<-- Liens du Wiki : <--
<-- Accueil du WIKI : <--
<-- Création de Projets <--
<-- Étapes de Développement <--
Et celui qui reste pour avancer est encore bien long (tant mieux).
Sans avoir, à tout réécrire, réorganiser son ancien projet en un nouveau, est un processus intéressant, permettant de mesurer ses propres progrès et continuer à s'améliorer.
Je vous donne, mes propres pistes empruntées :
gambas@gambas:$
- Créer un répertoire d'accueil, genre "DÉVELOPPEMENT", pour mes différents projets, chacun dans un répertoire dédié.
- Toujours regarder ce que l'IDE a fait pour moi, en lisant les fichiers qu'il produit ; comment les a t il écrit?
- Réorganiser mes documents inclus, par type, les déplacer dans des sous répertoires par type.
- Dans un formulaire, essayer de ne conserver que des variables et procédures Private.
- Déplacer les variables et procédures, nécessairement Public, dans un module, genre "MVar" pour les variables, "MProc" pour les procédures.
- Créer un module pour les appels à des procédures Public, spécifiques, du style Settings, Sons, autres, genre "MSettings", "MSons", ...
- Déplacer l'ouverture et la clôture du programme dans un module, souvent, le même, genre "MPrinc" pour module principal, s'il n'y a qu'un formulaire principal (pas obligatoire, mais...).
- Les formulaires sont le centre, la raison de l'IDE mais on peut essayer de s'en affranchir, sans réinventer la roue.
- Mais on peut mesurer le travail fait par celui-ci, et la facilitation obtenue, ainsi.
- M'astreindre, dans tous les cas, à bien nommer mes variables, en fonction de leur type et de leur statut, globales Private, globales Public, locales.
- Les regrouper, dans la déclaration, par type, séparés par une ligne vide (visuellement, c'est mieux).
- Jouer avec les mots Static Public, Static Private, Create Static ; de toute façon l'IDE va m'envoyer sur les roses si je fais quelque chose qu'il n'apprécie pas.
- Et, je vais pouvoir essayer, d'en apprendre, le pourquoi, pour me familiariser avec ces mots, et leurs implications.
- Reprendre mes commentaires, les aligner après 60 caractères "-" ou tiret du six. Cela prends tout son sens si on réduit chaque procédure.
- Lors de l'instanciation d'un objet, toujours s'astreindre à attacher un évènement à cet objet (Object.Attach).
- Toujours, générer une archive des sources, avant de changer de version de mon projet, car l'IDE va effacer l'avant dernière version.
- Que je range dans un répertoire d'archive de mes sources, genre "SOURCES", projet par projet.
- ...
- Créer un répertoire d'accueil, genre "DÉVELOPPEMENT", pour mes différents projets, chacun dans un répertoire dédié.
- Toujours regarder ce que l'IDE a fait pour moi, en lisant les fichiers qu'il produit ; comment les a t il écrit?
- Réorganiser mes documents inclus, par type, les déplacer dans des sous répertoires par type.
- Dans un formulaire, essayer de ne conserver que des variables et procédures Private.
- Déplacer les variables et procédures, nécessairement Public, dans un module, genre "MVar" pour les variables, "MProc" pour les procédures.
- Créer un module pour les appels à des procédures Public, spécifiques, du style Settings, Sons, autres, genre "MSettings", "MSons", ...
- Déplacer l'ouverture et la clôture du programme dans un module, souvent, le même, genre "MPrinc" pour module principal, s'il n'y a qu'un formulaire principal (pas obligatoire, mais...).
- Les formulaires sont le centre, la raison de l'IDE mais on peut essayer de s'en affranchir, sans réinventer la roue.
- Mais on peut mesurer le travail fait par celui-ci, et la facilitation obtenue, ainsi.
- M'astreindre, dans tous les cas, à bien nommer mes variables, en fonction de leur type et de leur statut, globales Private, globales Public, locales.
- Les regrouper, dans la déclaration, par type, séparés par une ligne vide (visuellement, c'est mieux).
- Jouer avec les mots Static Public, Static Private, Create Static ; de toute façon l'IDE va m'envoyer sur les roses si je fais quelque chose qu'il n'apprécie pas.
- Et, je vais pouvoir essayer, d'en apprendre, le pourquoi, pour me familiariser avec ces mots, et leurs implications.
- Reprendre mes commentaires, les aligner après 60 caractères "-" ou tiret du six. Cela prends tout son sens si on réduit chaque procédure.
- Lors de l'instanciation d'un objet, toujours s'astreindre à attacher un évènement à cet objet (Object.Attach).
- Toujours, générer une archive des sources, avant de changer de version de mon projet, car l'IDE va effacer l'avant dernière version.
- Que je range dans un répertoire d'archive de mes sources, genre "SOURCES", projet par projet.
- ...
gambas@gambas:$ Toute cette gymnastique, pour espérer que mes nouveaux projets soient, ainsi organisés, d’emblée.
Pour illustrer mon propos, voici une ossature de projet vide qui ne constitue pas, en aucune manière, un modèle, mais simplement, un chemin de réflexion que j'ai emprunté.
Ossature de Projet :
Il s'agit d'un projet traduisible avec un splash screen simple, modifiable, un menu réduit à alimenter en fonction de ses besoins.
Tout est dans la structure proposée.
Dans l'IDE :
- Des répertoires pour Modules, Formulaires, Tâches, Classes, et autres objets dont on pourrait avoir besoin.
- Des répertoires pour chaque type de données nécessaires au bon fonctionnement de notre application.
Les Classes, regroupées, elles, aussi, dans un endroit pour elles :
CObjetNecessaire, tous les objets nécessaires à votre application seront regroupés, là.
Rappelons qu'un objet est simplement une instance d'une classe.
Les formulaires prêts à l'emploi :
FAide, à construire selon ses envies.
FChoixPolice, pour choisir et modifier la police employée au niveau des formulaires.
FSplash, le splash screen, pour faire pro.
FMain, le formulaire principal de votre application, à développer.
Les Modules :
- Un module de début qui lance le programme et le termine.
- Un module par type d'action : sons, settings, langues, variables globales au projet, connexion à une base de données, éventuelle.
Genre : MSon, MSettings, MVar, MConn, ...
Task :
Un répertoire, enfin pour les TASKS dont nous pourrions avoir besoin :
CTaskNecessaire, c'est un fichier classe mais on le met à part pour bien le différencier.
Car tout est, ici dans la présentation et l'organisation de notre projet, en résumé dans sa structuration
Nous retrouvons l'ensemble de ces objets sur l'image suivante :
Qu'y a t il de particulier à procéder ainsi?
La structuration de notre projet doit nous permettre de bien structurer notre pensée et par là même notre réflexion par rapport au besoin que nous voulons exprimer dans notre application.
Un exemple, pour illustrer cette nécessité de structure,
-1-Le déport des variables globales au projet dans un module :
Quel est l'intérêt :
Nous regroupons les variables dans un seul endroit. Deux façons de procéder peuvent s'entrechoquer :
- regrouper les variables par provenance
- regrouper les variables par type
- ou même une troisième, par provenance et puis par type
Au début on aura tendance à les regrouper par provenance puis très vite on les regroupera par type, en s'apercevant que c'est plus intéressant, car leur type est plus important que leur provenance.
Petit rappel, un module est une région particulière, qui est Static et Public, ce qui protège vos variables car elles ne sont pas accessibles autrement que par des appels de votre application que vous aurez programmés.(voir les différences entre static et dynamic, sur le site.)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | PUBLIC iTemp AS INTEGER '<---------------------------------' durée du splash |
Il est vrai qu'il faudra ajouter "MVar." devant le nom de la variable quand il faudra l'appeler de n'importe où dans le projet.
Un mot sur cette procédure particulière :
-2-L'application de la langue sélectionnée par l'utilisateur.
Bien suivre, les mentions entourées d'étoiles, elles expliquent que le changement de langue ne peut se faire que par le redémarrage de l'application.
Quand, on effectue ses tests dans l'IDE, la première ligne doit être dé-commentée et la suivante commentée.
Quand on veut effectuer la compilation de son projet, au contraire on commente la première et dé-commente la seconde.
Cette ligne :
| 1 | SHELL "kill -9 " & Application.id |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | PRIVATE SUB AppliLangues() '<-----------------------------' application du choix de langue par redémarrage auto |
-3-Voici l'ensemble des procédures nécessaires à l'application des langues
dont nous aurons préalablement préparées les traductions.
Configuration de la langue enregistrée et du menu :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | '--------- Début Zone Application des langues ----------' |
Le menu Langue sélectionné :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | PUBLIC SUB MenuLangues_Click() '<--------------------------' choix de la langue et affichage du menu checked |
Application de la langue choisie :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | PRIVATE SUB AppliLangues() '<-----------------------------' application du choix de langue par redémarrage auto |
Une image du menu permettant de sélectionner la langue désirée :
Le Module de démarrage :
Le module de démarrage, MDebut en deux procédures, ouverture et fermeture.
Ouverture :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | PUBLIC SUB Main() '<---------------------------------------------' réglages et initialisations nécessaires au fonctionnement |
Fermeture :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | PUBLIC SUB Quitter() '<------------------------------------' sortie avec fermeture de tout ce qui doit l'être |
Bien sûr un module de démarrage et de fin n'est pas obligatoire, mais il oblige à bien penser ses initialisations et instanciations et lors de la clôture, il rassemble les objets dont il faut s'occuper pour réaliser une fermeture propre de l'application.
Le Splash Screen :
Le Splash Screen, n'est qu'une cerise sur le gâteau, un plaisir supplémentaire qui ne devrait se justifier que dans le cas où "beaucoup" de choses devraient être lancées avant que l'application ne démarre, pour faire patienter l'utilisateur. Ici, il ne s'agit que d'une "tricherie".
Déclarations minimales :
| 1 2 3 4 5 6 7 8 | PRIVATE $iCount AS INTEGER |
L'ouverture du formulaire :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | PUBLIC SUB Form_Open() |
Le travail du Timer :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | PUBLIC SUB Timer1_Timer() |
La fermeture du formulaire :
| 1 2 3 4 5 6 7 8 9 10 | PUBLIC SUB Form_Close() |
Cette ossature de projet vide ne constitue pas, encore une fois, un modèle, mais simplement, un chemin de réflexion que j'ai emprunté et tenais à partager.
Endroit de téléchargement sur la forge de ce projet : https://gambas-fr.org/code-279-ossaturedeprojet.html
====================
Navigation :
<-- Liens du Wiki : <--
<-- Accueil du WIKI : <--
<-- Création de Projets <--
<-- Étapes de Développement <--
====================
La Documentation :
- site officiel
- documentation officielle
- Gambas Linux
- Gambas Book (en anglais ou allemand) ou traduisible à la volée par Google Traduction : Translator
- Même page directement traduite en français
- Convention de Nommage des Variables
- Conventions de Nommage