Dans une suite de billets j’avais présenté une norme de nommage des différents éléments WinDev que je préconise et met en place lors de mes différentes programmations. Avec ce billet, je propose une amélioration sur le nom des procédures visant à améliorer la compréhension des traitements effectués par la celles-ci en lisant leur nom, pour cela j’ai mis en place un nouvelle partie dans le nom visant à isoler l’action de la procédure.Dans un premier temps nous allons voir la mise en place de cette amélioration pour les procédures globales, ensuite les procédures locales et pour terminer les procédures (généralement appelées méthodes) de classe.

Liste des billets sur les normes de programmation en WinDev :
• WinDev : normes de programmation pour les variables de type simple
• Windev : normes de programmation pour les procédures et les champs graphiques
• WinDev : normes de programmation pour la POO

Global au projet (Collections de procédures)

Les procédures déclarées dans une collection de procédures ont une portée globale au projet. Le nom sera composé de 3 parties :
• préfixe : obligatoire et fixe «GProc ». « G » pour globale au projet, « Proc » pour procédure ;
• action : obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions ci-dessous.
• nom : obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en majuscule.

Les trois parties seront séparées par le caractère « _ ».

Exemple :

Liste des actions :
• Afc : Affichage ;
• Ajt : Ajout ;
• Clc : Clic sur un bouton ;
• Ent : Entrée dans un champ ;
• Ini : Initialisation ;
• Lst: Récupération d’une liste de valeur ou une liste d’objet ;
• Raz : remise à zéro ;
• Rch : Recherche ;
• Rcp : Récupération d’une valeur ou d’un objet ;
• Sel : Sélection (ligne de table, combo) ;
• Sor : Sortie d’un champ ;
• Spr : Supprime/suppression ;
• Vrf : Vérification.

Cette liste est non exhaustive, elle doit être complétée/améliorée/modifiée selon les besoins de chacun. J’ai volontairement oublié l’action EXE, pour éviter une utilisation massive et/ou abusive, l’utilisation de cette action est réservée pour l’exécution requêtes SQL, Script, …

Local à un élément du projet

Les procédures déclarées dans un élément local du projet ont un portée local, elles ne sont pas accessibles depuis un élément extérieur. Le nom sera composé en 3 parties :
• Préfixe : Obligatoire et fixe «lProc ».
• Action : Obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions dans le paragraphe « Global au projet (Collections de procédures) ». 
• Nom : Obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en majuscule.

Les trois parties seront séparées par le caractère «_ ».

Exemple :

Classes

Les procédures de classes sont soit public, protégée, ou privée, dans la convention de nommage, cette notion n’est pas prise en compte, car lors de la programmation en objet, WinDev fait la complétion automatique en proposant uniquement les procédures avec une portée accessible. Le nom est composé de deux parties :
• Action : Obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions dans le paragraphe « Global au projet (Collections de procédures) ». Une exception est appliquée pour les procédures des gestions des requêtes, la partie action commence par « Exe »
• Nom : Obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en minuscule.

Exemple :

• Nouveauté 36 : graphes, nouvel aspect des bulles

Une amélioration intéressante pour l’utilisateur finale pour faciliter la lecture d’un graphe.

• Nouveauté 37 : Mire de lecture de graphe

Pour la même raison que la nouveauté 36, une amélioration intéressante pour l’utilisateur

• Nouveauté 46 : Une fenêtre D’IHM + une fenêtre de code simultanément à l’écran

Avec cette nouveauté, l’espace de travail s’améliore. un écran pour l’interface et un autre pour le code. Reste à convaincre les responsable des achats pour un deuxième écran

• Nouveauté 53 : Ordre de tabulations recalculé a chaque modification

Avec cette nouveauté, fini les oublis lors d’une modification d’IHM effectuée dans la dernière ligne droite du projet.

• Nouveauté 54 : Utilisation des ancrages en redimensionnement

Cette nouveauté entraîne un gain de temps et un respect des proportions existantes lors de modification d’IHM.

• Nouveauté 59 : Erreur d’IHM, champs avec bulles d’aide identiques signalées

Allez soyons honnête … Vious n’avez jamais oublier de modifier la bulle d’aide. Avec cette nouveauté WinDev nous le rappellera en erreur d’IHM.

• Nouveauté 63 : Centraliser les codes de mise à jour des champs d’une fenêtre
Alors cette nouveauté, c’est surement celle que je trouve la plus … à mon gôut au sens développement et lisibilité du code. Dans mes développements et mes explications sur WinDev je met en avant la centralisation du code de mise à jour des IHM dans les fenêtres pour :
• centraliser le code
• améliorer la lisibilité
• faciliter la ré utilisabilité
• faciliter les modifications

Je ne peux que inciter à l’utilisation de ce nouveau traitement

• Nouveauté 91 : MVP, comment l’utiliser facilement

Après la centralisation du code dans la nouveauté 63, la séparation des actions avec le Design Pattern MVP.
Impatient de voir le code à mettre en place pour utiliser ce Design Pattern

• Nouveauté 92 : Procédure interne

Avec cette nouveauté, on va pouvoir un niveau d’encapsulation et permette de diviser des parties de programmes procédural en sous taches qui n’ont d’intérêt et de sens que localement. Cela permet d’éviter l’accumulation de fonction globale qui ont un usage très restreint.

• Nouveauté 95, 96, 97 : Programmation parallèle

Ensemble de nouveautés intéressantes pour faciliter la programmation parallèle.

• Nouveauté 109 : Affectation multiples groupées

Enfin, un des gros manques des versions précédentes, je n’ai jamais compris pourquoi on pouvais déclarer sur une seule ligne des variables mais qu’il fallait plusieurs ligne ou bloc de code pour initialiser plusieurs variables

• Nouveauté 113 : Design Pattern façade (objets associés)

Cette nouveauté augmente les possibilités POO de WinDev.

• Nouveauté 125 : Coordonnées géographique, fonctions géoAzimuth et géoDistance

Ces deux fonctions sont très intéressantes pour des logiciels utilisant des cartes, des adresses, des tournées, …

• Nouveauté 203 : Jauge à progression infinie

Cette nouveauté met fin au code à plusieurs états pour afficher correctement une jauge infinie

Conclusion

Cette version de Windev emmène des nouveautés intéressantes autant que ce soit au niveau développement que graphique pour le client. Le nombre de 920 me parait gonflé, mais ça c’est l’aspect commercial, et cela devient une question d’habitude. Chacun qui verra un intérêt à migrer ou pas

Dans cet article, nous allons voir la mise en place du design pattern Stratégie de type comportemental.

Lire la suite de l’article

Un article expliquant comment mettre en place cette possibilité est disponible sur le site developpez.com : classes abstraites en WinDev (version antérieure à 19)

Les nouveautés intéressantes

001–>003 : Nouveau champ tableau de bord



Avec une expérience dans la gestion commerciale et dans le fiduciaire pour le transport de fond, il a souvent été évoqué d’ajouter un module « tableau de bord » au logiciel. Celui-ci aurait regroupé un ensemble d’analyses présentées différemment (tableau de chiffres, histogramme, courbe, …), développé pour les responsables pour avoir une vue d’ensemble de l’activité. Malgré les discussions régulières sur ce sujet, aucune de mes activités professionnelles m’a emmené à finaliser un tel module et souvent par manque de temps. Windev pourrait palier à cela avec cette amélioration, j’ai hâte de pouvoir manipuler ce nouveau champ.

009 –> 012 : Création d’un champ par programmation

Cette amélioration permet enfin de créer un champ par programmation en partant de 0. Fini l’obligation d’utiliser la fonction ChampClone. Windev prendrait-il une orientation langage Objet …

027 : Associer un champ à plusieurs plan

Tout programmeur qui utilise les plans a déjà été confronté à devoir mettre un champ sur plusieurs plans sans qu’il soit visible sur tous. Il y avait alors deux possibilités :
– Relier le champ au plan 0 et programmer sa visibilité –> Multiplication des lignes de codes
– Dupliquer le champ et l’associer aux plans souhaités –> Multiplication des champs graphiques

Cette amélioration permet simplement d’associer un champ à plusieurs plans sans multiplier ni le code ni les champs graphiques.

040 : Animation de graphe



Cette amélioration est purement graphique et esthétique, cela permet l’affichage d’un graphe progressivement et donne un rendu visuel intéressant. Si on couple cette amélioration au champ graphe, on peut imaginer une personne laissant afficher sur un écran un tableau de bord, il verrait alors les valeurs progressées

062 : Impression sur plusieurs pages



Cette amélioration permettra d’améliorer la présentation des analyses contenant un nombre d’informations importantes et ainsi d’éviter le tassement des données imprimées.

071 : Définition des images de fond des PDF augmentées



Il est souvent demandé par les clients d’informatiser des formulaires de saisie, ceux-ci ont une mise en page et une charte graphique particulière par exemple une image de fond. Une possibilité était d’associer en image de fond un JPEG du formulaire, mais le rendu était flou et ne satisfaisant pas le client. IL fallait donc passer pas mal de temps pour reconstituer au plus juste le formulaire dans l’état. Cette amélioration corrige le flou des images de fond et rend donc la possibilité de passer par un jpeg pour construire le formulaire client, le temps gagné est considérable et le rendu sera à l’identique.

094 : POO – classes abstraites

En un mot : ENFIN. Il était possible de simuler une classe abstraite en jouant sur les propriété d’accès du constructeur, voir l’article : Classes abstraites en Windev


100 : Paramètre de procédure : utiliser directement des éléments du projet

Création d’un champ par programmation, classes abstraites et passage d’un champ en parmètre, c’est clair, c’est l’année POO pour Pc-SOFT.

101 : Surcharger la fonction ouvre

Intéressant, en espérant que l’on pourra effectuer une vrai surcharge,en changeant la signature des paramètres et pas seulement une surcharge comme il existe déjà pour les fonction w-langage (cf exemple surcharge de la fonction trace). Cela permettra d’évitera l’accumulation de paramètres optionnels

PROCEDURE Trace(Information1)
Message("Lancement d'une trace")
WL.Trace(Information1)

102 –> 103 : Initialisation et affectation multiples de variables

Intéressant mais attention à ne pas tomber dans l’illisibilité de code.

127 : Erreur de compilation, complétion toujours active

PC-SOFT améliore enfin ce bug, gênant au quotidien. Lors d’une erreur de compilation, Windev ne gérait pu la complétion automatique de code , il fallait alors
1. Supprimer la ligne, et la re-saisir.

ou

2. Finir la saisie sans assistance.

141 –>145 : Gestion des types de transactions

HFSQL s’améliore et gère les différentes transactions SQL. Une amélioration qui me parait très intéressante dans le cas d’application multi-utilisateurs.

171 : Nouveau look des ascenseurs

Personnalisation plus poussée de l’interface graphique

Les nouveautés surprenantes

90 : Label automatique continuer

Avec cette « amélioration », j’ai l’impression que pc-soft essaye de relancer le GOTO, pour moi c’est purement une régression. Il est possible de palier à ce label par des instructions conditionnelles, de boucles, éventuellement en dupliquant des portions de codes et/ou en utilisant des variables intermédiaires. Cf théorème de Böhm-Jacopini sur le GOTO.

91 : Label automatique Sortir

Idem explications 90

Conclusion

Cette version de Windev emmène des nouveautés intéressantes autant que ce soit au niveau développement que graphique pour le client. Le nombre de 919 me parait gonflé, mais ça c’est l’aspect commercial. Personnellement, je suis moyennement convaincu de l’apport de cette version, néanmoins je la recommanderais pour les raisons suivantes :

• Demande sur le tableau de bord.
• Problème sur les transactions.
• Travailler sur une version 16 voir antérieur pour ne pas avoir plus de 3 versions de retard .

Modification apportée le 11.12.2013 grâce à une précision de zechatdoc.

L’Héritage c’est quoi ?

• Utiliser les champs hérités de la classe de base ( selon leur visibilité).
• Ajouter des nouveaux champs.
• Utiliser une méthode héritée ( selon la visibilité).
• Redéfinir une méthodes en la créant avec la même signature.
• Surcharger une méthode en la créant avec un signature différente.
• Ajouter une nouvelle méthode.
• Ajouter un ou plusieurs constructeur.

L’héritage par Windev par l’exemple

• Définition de l’exemple
Pour évoquer la notion d’héritage en Windev, je vais créer deux classes
ac_voiture : Classes pseudo abstraite (Cf un futur article sur les classes abstraites en windev) représentant une voiture.
pc_peugeot : Classes héritant de ac_voiture représentant une voiture de marque « Peugeot ».

Membres de la classe ac_voiture

PROTÉGÉE 
    ls_marque est une chaîne
    ls_modele est une chaîne
GLOBALE
    li_nbVoiture est un entier

Les membres ont des propriétés en lecture/éciture

//----->Propriété
PROCEDURE Marque() //Lecture
RENVOYER :ls_marque

PROCEDURE Marque(ps_marque est une chaîne) //Ecriture
:ls_marque = ps_marque

PROCEDURE Modele() //Lecture
RENVOYER :ls_modele

PROCEDURE Modele(ps_modele est une chaîne) //Ecriture
:ls_modele = ps_modele

Membres de la classe pc_peugeot

hérite de ac_voiture
PRIVÉE
    lb_moteurHdi est un booléen

Le membre a des propriétés en lecture/écriture

PROCEDURE moteurHdi() //Lecture
RENVOYER :lb_moteurHdi

PROCEDURE moteurHdi(pb_moteurHdi est un booléen) //Ecriture
:lb_moteurHdi = pb_moteurHdi
• Constructeur sans paramètre
Pour continuer notre exemple, nous allons créer le constructeur par défaut (Constructeur sans paramètre) pour chacune des classes.

Constructeur ac_voiture

PROCEDURE PROTÉGÉ Constructeur()
//---->Pas de code

Constructeur pc_peugeot

PROCEDURE Constructeur()
Ancêtre:Constructeur()
La première ligne fait appel au constructeur de la classe de base, WinDev n’oblige pas cet appel et ne l’effectue pas automatiquement (Cf langage JAVA), mais pour des questions de maintenance, de lisibilité et de compréhension, j’effectue toujours cet appel.
• Programme principale

Dans le code d’initialisation de la fenêtre je vais instancier un objet de type pc_peugeot.

lo_peugeot est un pc_peugeot()
• Constructeur avec paramètres.
Dans cette étape je supprime les constructeurs par défaut et supprime l’accès en écriture des membres. Je re-code des constructeurs en passant en paramètre les valeurs initialisation des membres. De cette façon, je force l’initialisation des membres de la classe par le constructeur.

Constructeur de la classe ac_voiure

PROCEDURE PROTÉGÉE  Constructeur(ps_marque est une chaîne,ps_modele est une chaîne)

:ls_marque=ps_marque
:ls_modele=ps_modele

Constructeur de la classe pc_peugeot

PROCEDURE Constructeur(ps_marque est une chaîne,ps_modele est une chaîne, pb_hdi est un booléen)

Ancêtre:Constructeur(ps_marque,ps_modele)
:lb_moteurHdi=pb_hdi

Au niveau de mon code principal, j’effectue certaines modification :

lo_peugeot est un pc_peugeot("Peugeot","308",Vrai)

Le code se compile, mais j’ai une erreur lors de l’exécution.

Erreur à la ligne 0 du traitement Constructeur de la classe pc_peugeot.
Les paramètres d’appel du code ‘Constructeur de la classe ac_voiture’ sont incorrects : on attendait 2 paramètres et on en a reçu 0.

Apres quelques recherches, j’ai isolé la ligne de code qui posait problème

hérite de ac_voiture

Si je traduis l’erreur de WinDev, à cette ligne de code, WinDev attend les 2 paramètres du constructeur de la classe ac_voiture. Cela veut dire que quand je déclare un objet de type pc_peugeot. Avant même que le constructeur de la classe instanciée soit appelé, le constructeur de la classe de base est appelé. Pour vérifier cette hypothèse, je vais ajouter une ligne trace dans le constructeur de la classe ac_voiture et recréer le constructeur par défaut (Pour ne pas avoir l’erreur d’exécution).
PROCEDURE PROTÉGÉE  Constructeur(ps_marque est une chaîne,ps_modele est une chaîne)

:ls_marque=ps_marque
:ls_modele=ps_modele

Trace("Marque : "+:ls_marque+" - Modele : "+:ls_modele)
PROCEDURE PROTÉGÉE Constructeur()

Trace("Marque : "+:ls_marque+" - Modele : "+:ls_modele)

Le résultat de la trace

Marque : – Modele :
Marque : Peugeot – Modele : 308

Mon hypothèse est validée, lors de l’instanciation d’un objet héritant d’une classe de base, Windev appelle automatiquement le constructeur de la classe de base. Ce qui me pose problème, c’est que cet appel n’est pas effectué dans le constructeur, mais lors de la liaison d’héritage : Hérite de ac_voiture.

Conséquences …

Rappel : Les membres statiques sont des champs ou méthodes qui sont accessibles par la classe elle même ou par toutes les instances de la classe. on parle également de membres partagés. Ils son très utiles lorsque vous avez à gérer dans une classe des informations qui ne sont pas spécifique à une instance de classe mais à la classe elle même.

Classe ac_voiture

Ajout du membre statique li_nbvoiture, déclaration de la classe

Propriété en lecture pour le membre li_nbVoiture

Modification du constructeur (Par défaut) pour incrémenter le membre statique

Classe pc_peugeot

Ajout du membre statique li_nbPeugeot

Propriété en lecture pour le membre li_nbPeugeot

Modification du constructeur (Par défaut) pour incrémenter le membre statique

Nous venons de terminer l’ajout des membres statiques à nos classes, maintenant nous allons modifier le code principale pour avoir afficher dans une trace le nombre de voiture et le nombre de peugeot instancié.

Résultat de la trace :

Voiture : 2 – Peugeot : 1

J’obtiens 2 voitures dont une Peugeot alors que je n’ai instancier qu’un seul objet.

Voila une des conséquences des appels prématurés automatiques, les données du programme sont erronées.
Ensuite je vais aussi insister sur le faite que nous sommes obligés d’avoir un constructeur par défaut dans la classe de base pour pouvoir mettre en place un héritage.

La subtilité

Conclusion

Les classes

La portée : Première lettre (a : abstrait, p : public).
le type : « c » comme classe suivi de « _ ».
Le nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Exemple :

Exemple :

Les membres

Exemple :

Les méthodes

Héritage

Exemple :

Les procédures (Et les fonctions ?)

La portée : Première lettre (G : Globale, l : locale).
le type : « Proc » comme procédure suivi de « _ ».
Le nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Exemple :

Gproc_calculDateFinContrat : Procédure globale qui calcule la date de fin de contrat.
lproc_calculMontantFacture : Procédure locale qui calcule le montant d'une facture.
lproc_EstSolder : Fonction qui renvoie vrai ou faux selon si la facture est soldée.

Les champs graphiques

Pour la norme sur les noms des champs le principe varie un peu, un champ graphique est forcément local, il n’y a aucun intérêt à ajouter la portée au nom. Le nom sera composé de :
type : cf liste suivi de « _ ».
nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Listes des champs :

Fenêtre : Fen –> Fen_nomDelaFenêtre
Fenêtre interne : FenI –> FenI_nomDelaFenêtre
Fenêtre modèle : FenM –> FenM_nomDelaFenêtre
Etat : Etat –> Etat_nomDeLEtat
Etat interne : EtatI –> EtatI_nomDeLEtat
Champ de saisie :Txt –> Txt_nomChamp
Bouton : Btn –> Btn_nomChamp
Image : Img –> Img_nomChamp
Sélecteur : Opt –> Opt_nomChamp
Interruptur : Chk –> Chk_nomChamp
Combo, liste : Cbx –> Cbx_nomChamp
Table : TAB –> TAB_nomChamp
Jauge : Jau –> Jau_nomChamp
• Windev permet de rassembler les champs en groupe, cela permet de consulter, modifier les caractéristiques des champs composant le groupe. Même principe que les champs graphiques, le groupe est local, on n’aura donc pas de notion de portée, le nom sera composé de
  Type : ‘grp’ suivi de « _ ».
  Nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

  Exemple :

  grp_boutons..visible=vrai

  Pour plus de renseignements sur les groupes voir la documentation sur le site de pc-soft : Documentation en ligne PC-Soft

• Je vais maintenant évoquer un cas qui m’a demandé d’aller plus loin dans le nommage des champs. Dans ma carrière de développeur d’applications, j’ai créé énormément de fenêtres, dans lesquelles sont affichés différents champs. Je vais faire simple, j’ai dû programmer une fenêtre d’exportation selon un nombre de critères importants (Civilité, Secteur géographique, Profession, etc..)
  Chaque critère est composé de 3 champs :
  • Une zone texte « Code » : Saisir le code.
  • Une zone texte « Libellé » : Affiche le libelle du code
  • Un bouton « Recherche » : Affiche dans un tableau l’ensemble des possibilités du critère

  .

  Au départ j’avais nommé mes champs
  • Code : txt_codeCritere
  • Libelle : Txt_LibelleCritere
  • Bouton recherche : Btn_RechCritere

  J’ai rencontré un petit souci quand j’ai commencé à coder la requête SQL. Je testais si le code du critère était renseigné, si oui je rajoutais une clause de sélection.

  Exemple de code :

  Si txt_CodeSecteur"" alors
       ls_requete+=" AND cli_secteur='"+txt_codesecteur+"'"
  fin
  Jusque là, vous ne voyez peut être pas de souçi, mon problème intervient avec la quantité de code. Quand on commence à taper le nom d’une variable, d’un champ ou autres objets Windev propose automatiquement une liste des champs qui commence par ce que l’on vient de saisir. Alors en commençant à saisir « Txt_code », je me retrouvais avec l’ensemble des critères de sélection, et donc une liste importante à parcourir. Alors qu’en inversant le nom du critère et le type d’information, on obtient :
  • Code : txt_Criterecode
  • Libelle : Txt_CritereLibelle
  • Bouton recherche : Btn_CritereRech
  Maintenant si je saisis « Txt_secteur », la liste affiche uniquement les champs Txt_secteurCode et Txt_secteurLibelle. La liste est diminuée, et donc plus confortable pour sélectionner le bon champs. je trouve que cette convention de nommage va plus loin dans l’organisation des champs et donne plus de souplesse lors de la codification.