Discussion :

[athos690]

Je travaille sur PB et Windev donc je pense pouvoir comparer les deux objectivement. Pour faire des applications de gestion de base de données client/serveur je pense qu'il n'y a pas mieux et plus simple que PB. J'ai toujours eu des problèmes pour faire avec Windev ce que je faisait en cinq minutes avec PB
Je ne vois pas non plus pourquoi tu dis que PB vient d'un autre âge, îl évolue comme tout langage, en ce moment je fait un appli qui communique avec des webservice (technologie plutôt récente), tu dis peut être ca parcequ'on ne peut pas faire des fenêtres qui clignotes et des boutons de toutes les couleurs ?...

Je ne parle pas du langage mais de l'interface globale de PB qui me paraît lourde et peu pratique.
Certes ce n'est qu'une première impression sur une version 11.5 que j'ai téléchargé récemment mais ce n'est pas très engageant.
Il ne s'agit pas de faire des trucs clignotants de toutes les couleurs mais au moins d'avoir du vrai WYSIWYG et de ce côté, ce n'est pas vraiment le top.
Je ne juge pas de la qualité et de la puissance du code généré, je ne connais pas assez ce produit pour me le permettre.
Une interface claire et ergonomique me parait être essentiel quand on doit y passer des heures.
Ce n'est qu'une première impression (qui est souvent la bonne) et il n'y a rien de définitif dans mes propos.

[bombseb]

ben du vrai WYSIWYG... c'est pas compliqué... tu met des controls sur une fenêtre, c'est le résultat que tu aura quand tu lancera ton appli

[athos690]

Le fait est que je trouve l'interface de WinDev particulièrement réussie d'où mes critiques un peu rapides.
Je viens de faire quelques tests avec PB et il semble qu'en cherchant un peu (beaucoup) on fini par s'en sortir...

[Jon Shannow]

Et on est reparti dans un

débat sans fin sur "truc vs machin"...

[athos690]

Bon juste un truc pour en rajouter une couche :

J'ai essayé la manip triviale suivante avec PB (version de test 11.5) et Windev14 :

Remplir 2 tableaux mémoire avec des lignes issues d'un fichier texte, soit 111088 lignes de 8 à 18 caractères de long (la moitié gauche de la ligne ajoutée au tableau A et la moitié droite ajoutée au tableau B).
C'est donc une simple boucle qui lit le fichier texte ligne par ligne et qui ajoute les valeurs aux tableaux après découpage en 2 parties de la ligne.

Après compilation :
Avec Windev il faut environ 2 secondes pour remplir le tableau.
Avec PB il faut environ 24 secondes avec un taux d'occupation du processeur de 25 % pour faire la même chose sur la même bécane (Intel core i5) et avec le même fichier source bien sûr.

De plus, l'application PB lancée occupe 13 Mo de mémoire avant le lancement du remplissage, l'application Windev n'occupe que 5 Mo avant le lancement du remplissage. L'application Windev est pourtant nettement plus complexe car j'ai greffé ce test sur une application existante alors que l'application PB ne fait que ça.

Le temps de génération de l'exécutable est aussi très différent en faveur de Windev. (au moins 10 fois plus rapide pour un nombre d'éléments nettement supérieur).

Bref, en terme d'efficacité du code il semble qu'il n'y ait pas photo et je ne suis pas du tout convaincu par les performances de PB d'autant que son prix est nettement plus élevé que celui de Windev et je crois qu'il faut payer des licences par poste au niveau des plug-in mais je ne suis pas sûr de ça...
Avec Windev et Hyperfile, on peut déployer à l'infini sans frais supplémentaires.
Et je ne parle pas du framework PB qui occupe nettement plus de place que celui de Windev pour faire la même chose en moins bien...

Si on ajoute à tout ça la facilité de déploiement d'une application Windev, il ne reste vraiment pas grand chose à PB.

Je me suis contenté d'un test très simple car je ne connais pas encore assez PB pour essayer des trucs très complexes, mais c'est assez significatif malgré tout.

Alors il reste les fameuses "DataWindows" oui et alors ?
Gérer des tables Fichiers ou requêtes sous Windev est enfantin et demande très peu de code...

Je vais néanmoins continuer mes tests en manipulant des gros fichiers de données avec Windev/Hyperfile d'un côté et PB/SQLanywhere de l'autre pour voir mais je n'ai guère de doute sur le résultat...

[bombseb]

on ne rempli pas un tableau avec le contenu d'un fichier texte juste par plaisir, quel était le but de la manip ? Comment tu la développé ?
J'utilise tres rarement des tableaux de variables avec PB car il y a beaucoup plus pratique.
Pour ton fichier texte, tu créé une datawindow avec deux colonnes et tu appel la fonction ImportFile () de ta dw. ca se fait en quelques lignes de codes, et ensuite tu peux trier, filtrer, générer des xls, génerer du sql, insérer dans une base et plein d'autres trucs tres facilement, t'a juste à utiliser les fonctions de la dw.

PB oui c'est sur que c'est un peu lourdingue d'installer le gros runtime, mais chaque outil à ses avantages et inconvénients.

Par exemple ce que je n'aime pas du tout avec Windev c'est les indirections, ca nuit à la lisibilité et ca fait vraiment bidouille. Pour faire une fenêtre MDI dans laquelle tu veux ouvrir plusieurs instances de la même fenêtre et bien tu ne peux pas faire autrement alors que dans n'importe quel langage objet ca se fait en 3 lignes de code (ou presque) :

- Déclaration du pointeur de fenêtre
- instanciation
- ouverture de la fenêtre

Je critique windev mais j'admet sans problème que pour faire certains trucs c'est bien pratique il y a des fonctions pour tout contrairement à PB qui est vraiment puissant uniquement pour la gestion de base de données bien qu'il soit quand même possible d'appeller l'api windows et donc de potentiellement faire ce qu'on veux.

[athos690]

C'était juste histoire de faire un test comparatif.
Je suis bien d'accord que ça n'a pas d'intérêt dans la pratique mais ça permet simplement de mettre en évidence des différences de rapidité notamment lors d'un traitement à l'intérieur d'une boucle...

[Arnaud B.]

Par exemple ce que je n'aime pas du tout avec Windev c'est les indirections, ca nuit à la lisibilité et ca fait vraiment bidouille. Pour faire une fenêtre MDI dans laquelle tu veux ouvrir plusieurs instances de la même fenêtre et bien tu ne peux pas faire autrement alors que dans n'importe quel langage objet ca se fait en 3 lignes de code (ou presque) :

- Déclaration du pointeur de fenêtre
- instanciation
- ouverture de la fenêtre

Tu mets en évidence une limite fondamentale de Windev qui est que l'on ne peut manipuler les classes de l'EDI... et notamment les fenêtres.

C'est dû à l'orientation faiblement objet de Windev à l'origine. On note cependant une petite évolution car on voit que de plus en plus, Windev met à disposition des sortes d'objets (l'objet Email par exemple), malheureusement simplifiés (pas d'héritage par exemple).

Face à ça, je préfère disposer des indirections que ne rien avoir du tout, car sinon on serait très limités par cette impossibilité d'accéder aux classes.

Personnellement, j'ai l'habitude de créer des objets Fenêtre, Table, etc... qui manipulent les objets concernés via les fonctions Windev et les indirections.

Une chose qui me gêne particulièrement par rapport à la conception de Windev, c'est le "contexte Hyperfile".
On peut le déclarer "indépendant" pour une fenêtre, un état... et maintenant une classe (en version WD16 il me semble).

Ce serait quand même plus puissant et plus cohérent d'avoir un objet Contexte qu'on puisse instancier quand on a besoin d'ouvrir un nouveau contexte Hyperfile indépendant !

Cdlt, Arnaud.

[NetLandGim]

Pour ceux qui viennent du monde POO
Essayez de fricoter avec l'utilisation des classes de Windev

Windev ne permet pas une transparence des opérations.
On ne peut pas construire un objet de rien!
Tu veux créer une table, il faut partir d'une présente et la cloner
Une fenêtre c'est pareil. Il n'ya pas de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

JFrame myFrame =new JFrame();

On attend de voir si on pourra avoir un jour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
maFenetre est une Fenetre
maFenetre.Largeur =500
maFenetre.Hauteur= 400
maFenetre.Titre="Fenetre venue de nulle part"
Créer(maFenetre)

Windev est destiné à tout le monde! Permettre à un utilisateur de créer un programme pour ses besoins! C'est comme utiliser MS Excel pour sa compta!

Mais avec windev on peut faire des merveilles

[NetLandGim]

Face à ça, je préfère disposer des indirections que ne rien avoir du tout, car sinon on serait très limités par cette impossibilité d'accéder aux classes.

Cdlt, Arnaud.

Les débutants en développement ne se soucient gèrent de l'indirection .
C'est ceux qui viennent du monde POO qui sont obligés d'envoyer des cabris à la chasse à la place des chiens . C'est ce qui me déroute un peu chez windev

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
PROCEDURE Ev_Ouvre_Fenetre(MessageWindows<utile>, wParam, lParam<utile>)
NomFenetre est une chaîne=ChaîneRécupère(wparam,crAdresseASCIIZ)


SI FenEtat({NomFenetre,indFenêtre})=Inexistant ALORS
Ouvre({NomFenetre,indFenêtre})
FIN

[dvdbly]

Quoiqu'il en soit, d'accord avec NetLandGim : la limite la plus importante reste de ne pas pouvoir coder la création de champs ex nihilo, ni de fenêtres d'aucune manière.
Et visiblement, combler cette lacune n'est pas à l'ordre du jour...

[Arnaud B.]

Quoiqu'il en soit, d'accord avec NetLandGim : la limite la plus importante reste de ne pas pouvoir coder la création de champs ex nihilo, ni de fenêtres d'aucune manière.
Et visiblement, combler cette lacune n'est pas à l'ordre du jour...

Face à cette limite, une méthode de contournement que nous avons adoptée est :
- avoir une fenêtre "mère" qui contient un exemplaire de chaque champ utile
- une classe qui manipule cette fenêtre, et qui permet d' "instancier" les champs (en réalité de les dupliquer par ChampClone)

C'est un peu lourd à construire, mais à l'usage c'est pratique

Cdlt, Arnaud.

[mnw.william]

J'ai lu toutes les suggestions de tout un chacun mais je pense de ma part que Windev à partir de la version 12 à les capacités que les EDI comme Visual Basic nous proposent et encore plus.

Vous pouvez lire les témoignages des professionnels qui ont réalisés des gros projets sur le liens suivant

http://www.pcsoft.fr/pcsoft/temoignages.html

Donc c'est un peu ca. Et notons aussi que Windev est le seul EDI qui propose le développement en équipe et un GDS entre autre.

cdt,

[Lo²]

Certes mais ces témoignages sont un peu sur le site PCSOFT et je ne pense qu'il mette des témoignages qui descendent Windev

A part cela, j'adore Windev

[dvdbly]

Face à cette limite, une méthode de contournement que nous avons adoptée est :
- avoir une fenêtre "mère" qui contient un exemplaire de chaque champ utile
- une classe qui manipule cette fenêtre, et qui permet d' "instancier" les champs (en réalité de les dupliquer par ChampClone)

C'est un peu lourd à construire, mais à l'usage c'est pratique

Cdlt, Arnaud.

Bonjour Arnaud,

Merci pour ces explications.
Toutefois, cela ne permet pas de créer de nouvelles fenêtres, si je ne me trompe ; seulement de "nouveaux" champs.
Est-ce donc à dire que la fenêtre est "reprogrammée" en fonction du contexte appelant ? Et la liaison avec la base de données adaptée de même ?

Cordialement,
David

[WebPac]

Donc c'est un peu ca. Et notons aussi que Windev est le seul EDI qui propose le développement en équipe et un GDS entre autre.

Tous les autres IDEs le permettent aussi, Visual Studio travaille avec Team Fondation System et mais aussi avec SVN.
Delphi le permet aussi.

Je dirais même plus, les autres IDEs ne sont pas limités à ne travailler qu'avec un seul gestionnaire de sources propriétaire car les sources ne sont pas des fichiers binaires mais des fichiers textes.

[_skip]

Tous les autres IDEs le permettent aussi, Visual Studio travaille avec Team Fondation System et mais aussi avec SVN.
Delphi le permet aussi.

Je dirais même plus, les autres IDEs ne sont pas limités à ne travailler qu'avec un seul gestionnaire de sources propriétaire car les sources ne sont pas des fichiers binaires mais des fichiers textes.

C'est un aspect que j'ai aussi regretté car cela bloquait la génération de code. Je ne sais pas si c'est toujours le cas.
Pour ce qui est du GDS, A l'époque seul un utilisateur avait accès en modification à la fois, je ne sais pas si la version actuelle est plus souple en ce sens. Ca a le mérite d'exister mais quand on voyait les possibilités de merge des autres systèmes de gestion de source, c'était un peu derrière.

En revanche je suis assez d'accord pour dire que windev est un outil plutôt complet. Outil de modélisation, éditeur d'état d'impression, éditeur de tests unitaires, éditeur d'installeur... Il est clair que pour certains types de projet, aucun outil externe n'est nécessaire, ou presque.

[tatayo]

Si je ne me trompe pas, un seul utilisateur peux extraire un élément à un instant donné.
Ce qui me dérange le plus dans ce système, c'est la granularité: si un développeur veux modifier une procédure dans une collection de procédures, il doit extraire la collection, et ainsi "bloquer" toutes les procédures de la collection. Idem pour les fenêtres.
Celà étant dit, ce n'est pas bloquant chez nous car "chacun bosse sur ses projets".

Tatayo.

[hpascal]

Ceci dit, le GDS est quand même très pratique et même seul il y a tout intérêt à l'utiliser : historique des versions de chaque élément, comparaison de versions, création de branches ...
De plus les plantages présents dans des versions précédentes de Windev sont beaucoup plus rares (aucun pour moi)

[Arnaud B.]

Bonjour Arnaud,

Merci pour ces explications.
Toutefois, cela ne permet pas de créer de nouvelles fenêtres, si je ne me trompe ; seulement de "nouveaux" champs.
Est-ce donc à dire que la fenêtre est "reprogrammée" en fonction du contexte appelant ? Et la liaison avec la base de données adaptée de même ?

Cordialement,
David

Le principe est en fait d'avoir une fenêtre "standard", avec tous les champs nécessaires, invisibles.

Pour "créer" une nouvelle fenêtre, on ouvre la fenêtre "standard", en lui passant un objet (cDescriptionFenetre) qui contient tous les paramètres nécessaires à la configuration de la fenêtre (la source de données, les colonnes à afficher dans la table...)

Dans la fenêtre en question, l'objet est récupéré en ouverture, puis un traitement duplique les champs nécessaires par ChampClone (par exemple les colonnes de la table), lit la source de données, etc... puis rend la fenêtre visible.

C'est un peu compliqué à mettre au point, mais après ca fonctionne bien.

Et après des années de Windev, je n'ai trouvé que ce moyen pour avoir des fenêtres créées dynamiquement.

Cdlt, Arnaud.