Bonjour à tous,
Pour ma part, ça fait maintenant un peu plus de 2 ans que je travaille activement avec Windev. J'ai eu l'occasion d'expérimenter les versions 16 (Pas longtemps), 17 et 18 (Et bientôt la 19).
Je n'ai donc pas d'expérience sur les anciennes versions, mais d'après ce que j'ai pu lire sur les forums & cie, effectivement, il y a eu beaucoup de progrès effectués, notamment depuis la v11.
Ce que j'en pense ? Il est vraiment excellent, mais pour moi, à ne pas mettre entre toutes les mains. A noter que je ne parle ici que de Windev. J'ai eu l'occasion de voir les sorties de code de Webdev, et clairement, si Windev est un atout, Webdev est à fuir comme la peste pour de la prod de sites et applis web.
Déjà, je le déconseille clairement pour débuter, car l'un de ses gros points fort est qu'il mache pas mal de boulot pour nous, et donc pour apprendre, c'est clairement pas une bonne chose.
En gros, j'estime que pour bien utiliser Windev, il faut déjà savoir faire tout ce qu'il fait dans un autre langage de programmation "à la paluche". Ca permet de bien comprendre ce qui se passe, et de ne pas faire n'importe quoi.
Pour résumer les points forts :
- L'interface graphique des applis se fait en visuel. Pas de code à réaliser.
- Programmation sous forme événementielle, particulièrement adaptée à de l'informatique de gestion. Par exemple, pour un bouton, on a le code d'initialisation, le code déclenché au clic, au survol, au double clic, etc. Pour un tableau (une table, dans le vocabulaire Windev), on va avoir le code d'initialisation, de sélection d'une ligne, d'entrée et de sortie d'une ligne (on peut modifier des contenus de tables à la volée), etc., et la même chose colonne par colonne. Bref, une gestion d'événement sur les différents éléments graphiques assez complète, qui laisse un grand nombre de possibilités.
- Editeur d'analyse bien foutu, permettant une représentation graphique MERISE de la BDD, avec une gestion des contraintes d'intégrité bien foutue aussi.
- Multi-BDD
- Editeur de requête plutôt bien foutu, qui accélère grandement la rédaction de requêtes (il a aussi ses limites, j'en parlerai dans les points négatifs)
- Gestion de la POO
- Gestion de composants plutôt bien faite. Ca permet de réaliser des fonctions, fenêtres & autre dans un composant, réutilisable ensuite dans plusieurs applis. L'intégration dans les applis est bien gérée, la mise à jour du composant aussi, bref, c'est agréable. (En composant, j'ai fait un éditeur de règles de calcul formel avec les fonctions réalisant le calcul à partir de valeurs données et un gestionnaire de licences pour les logiciels que je développe).
- Pas mal d'éléments internes bien foutus, avec leurs limites, certes, mais qui aident beaucoup quand même. Par exemple, les champs Agenda et Planning, qui fonctionnent très bien (sauf l'alimentation automatique des rendez-vous depuis la base de données, qui fonctionne, mais est très restrictive. Perso, je gère l'alimentation en manuel, et utilise le reste des fonctions automatiques de ces deux champs).
- J'en oublie sûrement ^^
Et les points faibles :
- Si on ne sait pas faire à la paluche ce que fait une fonction ou un champ "tout fait" de Windev, on se demande assez vite comment il fonctionne exactement
- L'éditeur de requête a ses limites. Particulièrement en cas de jointures multiples avec un mix de jointures internes et externes sur un nombre de tables assez important (au dela de 6/7 tables, il se viande régulièrement). Par contre, je vois souvent des personnes râler à cause de ça, mais pourtant, il existe une solution extrêmement simple à la portée de tout développeur digne de ce nom : On retrousse ses manches, on passe en édition manuelle de la requête, et on tape son code SQL à la paluche ! On le fait bien dans d'autres langages, pourquoi ne pas le faire ici quand l'éditeur atteint ses limites ?
- Les tableaux associatifs sont encore très limités (et ça, ça m'emm**** sérieusement). Notamment, on ne peut pas faire de recherche sur les clefs. Cela dit, comme tout problème, il peut se contourner. Pour le cas des tableaux associatifs, même si ça fait deux lignes de code en plus, on contourne le pb en alimentant un tableau de chaines avec les clefs utilisées dans le tableau associatif, et on a résolu le problème.
- Je vais détailler un peu plus un des gros points noirs de Windev, pour tenter de mieux décrire le genre de problème qu'on peut rencontrer.
Windev dispose d'un mécanisme permettant d'accéder et de modifier très facilement la BDD. Par exemple, je veux ajouter un contact dans ma table contact. Je fais ainsi :
Code:
Contact.Nom = "DUPOND"
Contact.Prénom = "Jean"
Contact.age = 32
hAjoute(Contact)
nIDNouveauContact est un entier = Contact.IDContact
A noter que ces deux dernières lignes peuvent se noter en anglais sans pb :
Code:
HAdd(Contact)
nIDNouveauContact is int = Contact.IDContact
Toutes les fonctions Windev, les mots-clef, etc. en français ont leur homologue en anglais, et peuvent être traduits via un simple clic dans l'éditeur de code.
MAIS ! Contrairement à ce que préconise Windev dans son aide (plutôt bien faite, il faut le reconnaître), je déconseille FORTEMENT l'utilisation de ce mécanisme pour parcourir les données d'une table si vous n'êtes pas sûr que ces données ne peuvent pas être modifiées ailleurs au même moment. En effet, si vous lisez le contact d'ID 5, pour modifier son âge :
Code:
HLitRecherchePremier(Contact,IDContact,5)
Contact.age++
hModifie(Contact)
Pas de pb. Seul l'enregistrement d'ID 5 est concerné.
Mais si vous avez des fonctions travaillant en Ping-Pong, par exemple : Vous recherchez dans une première fonction les "Contact" correspondant à une personne adulte :
Code:
HLitRecherchePremier(Contact,DateNaissance,Vrai)
TANTQUE HTrouve(Contact)
AfficheLesEnfantsDuContact(Contact.IDContact)
HLitSuivant(Contact)
FIN
et que dans la fonction AfficheLesEnfantsDuContact(), vous refaites une nouvelle recherche sur le fichier contact avec HtlitRecherchePremier (ou toute autre fonction Hxxx de Windev), vous "cassez" le parcours intial, car la couche d'accès à la base en utilisant le nom des tables et de leurs rurbriques (Sous la forme table.colonne) est globale, et non locale à la fonction en cours. Si vous lisez un enregistrement de Contact dans une fonction, c'est celui-là qui sera accessible via Contact.xxx dans TOUTES les fonctions/fenêtres/classes & autres parties de votre logiciel.
C'est encore pire quand vous devez gérer l'accès aux données dans une fonction récursive.
Mais alors comment faire pour palier à ça ? Bah c'est très simple, on programme correctement : On fait des requêtes !
Le mécanisme décrit ci-dessus est par contre vraiment très pratique pour gérer les ajouts/modifications/suppressions d'enregistrements, et personnellement, j'en use sans modération, sans problème.
Bref, pour conclure, Windev est loin d'être parfait, c'est indéniable. Mais chacune de ses lacunes peut être comblée en mettant les mains à la pâte, sans en faire plus que dans un autre langage de programmation.
Mais passé ces quelques lacunes, il permet vraiment de gagner un temps considérable, particulièrement pour tout ce qui est logiciels de gestion.
Le gros défaut à ne pas attraper en utilisant Windev (Je l'ai chopé au début, je l'ai corrigé depuis) : Tout va tellement vite que quand on atteint une des limites de Windev, on peste parce que ça marche pas. Il faut juste prendre son mal en patience, coder à la main ce qui pose problème, comme on l'aurait fait avec un autre langage, et c'est fait. Même si c'est plus long qu'avec les mécanismes internes de Windev, c'est pas plus long qu'avec un autre langage, et au final, sur le reste, on continue de gagner du temps.
Cela dit, comme je l'ai dit au début, et j'insiste sur ce point, si vous ne savez pas programmer convenablement dans un autre langage, et que vous ne savez pas faire l'essentiel de ce que "mache" Windev à la paluche, oubliez de suite ce logiciel, sinon, vous ferez immanquablement une véritable usine à gaz.
Désolé pour le pavé, et en espérant que ça aidera d'autres personnes dans leur choix !
