Discussion :

[Ry_Yo]

...

Autre limite : impossible de passer la valeur Null à un paramètre,
car

Code :

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

requete.parametre = Null

conduit à ignorer le paramètre, et non pas à sélectionner les valeurs égales à Null.
En fait, on ne peut pas paramétrer IS NULL avec les requêtes de HF.

Compte tenu de ces limitations, on est très vite obligé en pratique d'utiliser des requêtes SQL dont on définit le code en fonction des critères voulus.

Avec Windev si on doit passer des Null en paramètre on a 1 méthode :

Code :

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

1
2
qsel_Client.paramPrenom..Null = Vrai
SI PAS HExecute....

[Hemgé]

Tout à fait,

On construit une requête avec l'éditeur de requêtes, puis on bascule dans l'écran Editeur de code SQL avec F2 et on a le code SQL de la requête, lequel peut alors être copié pour être affecté (collé) dans une variable chaîne de caractères de la fenêtre d'édition de Wlangage.

La requête initiale peut être simplissime ou plus développée, son utilité principale étant de permettre de bénéficier de la complétion des noms de colonnes (rubriques) et de tables (fichiers ).

[laurent30s]

Sinon personnellement j'utilise une méthode de contournement :
- je créé dans l'éditeur de requêtes une requete avec dans la clause SELECT les colonnes dont j'ai besoin (peu importe les autres clauses du moment que c'est correctement reconnu par Windev)
- comme ça j'ai l'autocomplétion, je peux relier cette requête aux tables, combos, colonnes... avec l'interface.
- MAIS je rédéfinis le code SQL de cette requete par programmation, pour avoir plus de souplesse/puissance (donc j'exécute la requête avec HExecuteRequeteSQL(marequete, sCodeSQL))

Génial ta méthode !
Je viens de la tester ça marche nickel...
Tout le code pour remplir la table n'est plus nécessaire
Quand on veut ajouter des colonnes plus besoin de se soucier de leur ordre
Que de temps gagné

Un grand merci pour ton astuce +1

[Arnaud B.]

Avec Windev si on doit passer des Null en paramètre on a 1 méthode :

Code :

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

1
2
qsel_Client.paramPrenom..Null = Vrai
SI PAS HExecute....

C'est l'équivalent de IS NULL ?
C'est génial si c'est le cas, car ça me manquait depuis des lustres...

Merci, je m'en vais tester ça de suite.

[SevenSoftware]

Merci Arnaud B. pour l'astuce.

C'est à moitié écrit dans l'aide de HExecuteRequeteSQL(), au paramètre
<Nom de la requête> ils mettent:

Code :

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

Si une requête de même nom est déjà déclarée, elle est remplacée par la nouvelle requête.

Ca n'exclue effectivement pas que la requête remplacée soit une requête WDR.

Par contre, ils se contredisent plus loin dans les notes:

Code :

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

Pour accéder aux rubriques de la requête, il FAUT déclarer une variable de type Source de données

Là, c'est faux, ils suffit que cette source de données existe déjà, ce qui est le cas d'une requete WDR.

[OnePoint]

Bonjour,

Je vais enrichir la liste des erreurs de conception et des limitations (pour certaines inacceptables), qui concernent principalement le WLangage.
Voici en vrac, des constats et critiques glanés ici et là :


Pas de possibilité de fixer la taille de la pile utilisée par l'exécutable.

Pas de projet de type Console.

Exceptions et erreurs :
• les erreurs sont gérées différemment selon les groupes de fonctions; la gestion des erreurs manque d'homogénéité.
• les exceptions de niveau application sont identifiées par un n° compris entre 1 et 1000: c'est "l'âge de pierre" !
• impossible de déclencher des exceptions réservées par Windev (n° supérieur à 1000) pour simuler/provoquer des erreurs fatales (c'est un vrai besoin en particulier pour les tests ; ce n'est pas un gadget).

Programmation récursive :
La récursivité est bridée à une profondeur de 600 appels, on se demande bien pourquoi !
(non, il n'y a pas de bonne raison. Inutile de chercher pourquoi, ni d'argumenter. Rien ne justifie ça.)
Il faudrait au moins permettre aux programmeurs avertis de fixer eux-mêmes la limite qu'ils veulent s'imposer.

Type de données Structure :
Impossible d'affecter aux membres une valeur par défaut.

Constantes :
impossible de les typer.

Variables et portées :
• Dans une collection de procédures, pas possible de définir une variable de portée locale à la collection.
• Impossible de déclarer une variable statique.
• "Fausse bonne idée" des variables d'itération qu'il n'est pas nécessaire de déclarer. Pratique ? peut-être, mais rigoureux sûrement pas.

Questions:
(1) comment le compilateur devine-t-il le bon type de de données à utiliser ?
(2) (exemple vécu) en cas d'erreur de frappe, on se retrouve avec 2 variables: une première déclarée explicitement et une deuxième (celle avec une faute de frappe) déclarée "automatiquement".
Un bug de programmation difficile à détecter pour les débutants.

Fonctions bloquantes non-interruptibles :
par exemple les fonctions d'archivages, fonction HTTPRequête...
A défaut de les rendre interruptibles, un fonctionnement asynchrone pourrait être proposé.

POO :
• Impossible d'indiquer qu'une classe est non-instanciable, ou non dérivable.
• A ma connaissance, pas de notion de membre "ami" (friend), ce qui serait bien pratique, par exemple pour autoriser l'accès au constructeur, pour les seules autres classes du projet.
• Pas de constructeurs multiples (cf. multisyntaxes), ce qui oblige (1) à définir des signatures compliquées et (2) à décoder les cas d'usage.
• Impossible de définir une interface pour réaliser une itération directement sur une instance qui implémente une "collection".
• Pas de notion d'événements.
• Pas de notion de classes d'exceptions.

Très grave à mon avis :
créer des fonctions WLangage de "1er rang" pour accéder à des fonctionnalités qui ne sont pas fournies par le framework Windev, et donc pas maîtrisées par PC SOFT.
Exemple API tierces type API Web Google. http://faq.pcsoft.fr/faqread.awp?idfaq=81478
A la place de fonctions WLangage, PC SOFT devrait fournir des bibliothèques "binding" vers ces API tierces.

Technologie COM / OLE implémentée superficiellement :
• il manque un "vrai" type variant COM sous le contrôle de l'utilisateur (la conversion entre les types WLangage et Variant COM est effectuée durant les appels / retours de fonction avec parfois une implémentation insuffisante).
• le WLangage procure un équivalent limité du CreateObject() (monikers non supportés), et pas d'équivalent au GetObject().
• le parcours des collections et autres variant/tableau n'est pas prévu avec l'instruction POUR TOUT du WLangage (interface IEnumVARIANT).
• champ ActiveX, impossible d'accéder aux propriétés du contrôle pour les renseigner dans l'EDI Windev.
• champ OLE implémenté à 20% de ce qui existe ailleurs, ce qui rend ce champ sans intérêt.
• presse-papiers OLE limité.

Manque d'homogénéité entre les plateformes ou les produits, par exemple :
• nombreuses fonctions indisponibles pour les projets Windev Linux.
• sous Windev,impossible d'utiliser la fonction fExtraitRessource pour accéder librement aux ressources intégrées (images, icônes, fichiers divers).

Toujours sur les ressources, à ma connaissance, il est impossible de les énumérer.

[mail.spam]

Bonjour,

• impossible de déclencher des exceptions pour simuler/provoquer des erreurs fatales (c'est un vrai besoin en particulier pour les tests ; ce n'est pas un gadget).

Je ne sais pas si c'est bien de cela dont tu parle mais la fonction ExceptionDéclenche permet de déclencher le mécanisme de sécurité du WLangage en provoquant une exception de niveau "applicatif" définie par le développeur

• Dans une collection de procédures, pas possible de définir une variable locale à la collection.

Lorsque tu fait un clic droit sur la collection de procédure puis code (ou F2) tu as accès à la déclaration de la collection de la procédure et ainsi tu peux définir des variables pour la collection.

Peux tu me dire si c'est bien de cela dont tu parle?

[tatayo]

Type de données Structure :
Impossible d'affecter aux membres une valeur par défaut.

C'était possible avant, mais ça, c'était avant... C'est une vraie régression.

POO :
• Impossible d'indiquer qu'une classe est non-instanciable, ou non dérivable.

Pour rendre une classe non instanciable, il suffit de déclarer le constructeur privé. La seule façon d'instancier une telle classe est qu'elle propose une méthode globale qui renvoie une instance. Utile pour un Singleton par exemple.

• A ma connaissance, pas de notion de membre "ami" (friend), ce qui serait bien pratique, par exemple pour autoriser l'accès au constructeur, pour les seules autres classes du projet.

Gros manque en effet !

Tatayo.

[Arnaud B.]

Bonjour,
"Fausse bonne idée" des variables d'itération qu'il n'est pas nécessaire de déclarer. Pratique ? peut-être, mais rigoureux sûrement pas.

Questions:
(1) comment le compilateur devine-t-il le bon type de de données à utiliser ?
(2) (exemple vécu) en cas d'erreur de frappe, on se retrouve avec 2 variables: une première déclarée explicitement et une deuxième (celle avec une faute de frappe) déclarée "automatiquement".
Un bug de programmation difficile à détecter.

C'est bien vrai, je me suis encore fait avoir hier....
M'enfin bon, c'est qu'un petit inconvénient...

Bonjour,
Pas de constructeurs multiples (cf. multisyntaxes), ce qui oblige (1) à définir des signatures compliquées et (2) à décoder les cas d'usage.

Il me semblait que c'était possible depuis wd17 ou wd18 non ? Quelqu'un peut confirmer ?

Bonjour,

Très grave à mon avis :
créer des fonctions WLangage de "1er rang" pour accéder à des fonctionnalités qui ne sont pas fournies par le framework Windev, et donc pas maîtrisées par PC SOFT.
Exemple API tierces type API Web Google. http://faq.pcsoft.fr/faqread.awp?idfaq=81478
A la place de fonctions WLangage, PC SOFT devrait fournir des bibliothèques "binding" vers ces API tierces.

C'est vrai que c'est très risqué... On l'a encore vu récemment.

Dans tous les cas, merci OnePoint pour ce "tableau" d'ensemble, c'est très intéressant.

[OnePoint]

Merci pour vos réponses,

• impossible de déclencher des exceptions pour simuler/provoquer des erreurs fatales (c'est un vrai besoin en particulier pour les tests ; ce n'est pas un gadget).

Je ne sais pas si c'est bien de cela dont tu parle mais la fonction ExceptionDéclenche permet de déclencher le mécanisme de sécurité du WLangage en provoquant une exception de niveau "applicatif" définie par le développeur

J'ai manqué de précision. Je parlais de déclencher des exceptions "réservées" par Windev (n° supérieur à 1000).

Je crois que sur DVP il y avait justement une discussion sur "Comment déclencher des exceptions HyperFile ?" pour effectuer des tests. Et rien n'est prévu.

• Dans une collection de procédures, pas possible de définir une variable locale à la collection.

Lorsque tu fait un clic droit sur la collection de procédure puis code (ou F2) tu as accès à la déclaration de la collection de la procédure et ainsi tu peux définir des variables pour la collection.

Là je parle d'une portée locale, c'est-à-dire que la variable ne puisse pas être lue/modifiée en dehors de la collection de procédures.

POO :
• Impossible d'indiquer qu'une classe est non-instanciable, ou non dérivable.

Pour rendre une classe non instanciable, il suffit de déclarer le constructeur privé. La seule façon d'instancier une telle classe est qu'elle propose une méthode globale qui renvoie une instance. Utile pour un Singleton par exemple.

Effectivement, un constructeur privé.

Merci à vous deux.

P.S. j'ai corrigé mon précédent message pour tenir compte de vos remarques

[Tober]

Je me faire un peu l'avocat du diable ce coup là, mais des fois, il faut savoir aussi relativisé les manques de WinDev.
Le post de OnePoint est interessant et soulève beaucoup de manque dans WinDev, mais est-ce bien le crénaux de WinDev ?

Exemple : récursivité limité à 600 appels.
1. Beaucoup de langage ont une limite et 600 appels récursifs c'est énorme.
2. Si on atteint la limite en cas réel (ce qui devrait pas vous arriver souvent), on peut écrire une fonction équivalente non récursive... (bref c'est aussi contournable)
3. Sérieusement et objectivement : est ce que vous utilisez souvent des fonctions récursives ? J'en ai utilisé quelques fois, mais juste pour mon plaisir personnel car c'était parfaitement faisable différemment...

Je veux pas dire que ce qui a été dit est inutile, mais pour moi les points cités par OnePoint relève plus d'un langage comme C++ ou équivalent où on demande vraiment une grande rigueur et de grandes performances...

Et comme cité plus haut, les problèmes de POO il y en a, mais WinDev n'est pas un langage Objet et donc vouloir a tout pris codé en objet avec WinDev, c'est comme vouloir programmer en procédural en Java. C'est possible mais c'est pas ça.

Sinon, pour tout le reste, je suis d'accord, WinDev a beaucoup de problèmes.

[Nicolas_Jeanneau]

3. Sérieusement et objectivement : est ce que vous utilisez souvent des fonctions récursives ? J'en ai utilisé quelques fois, mais juste pour mon plaisir personnel car c'était parfaitement faisable différemment...

Oui, tous les jours mes programmes en utilisent ! Je ne mets pas un point d'honneur à en utiliser mais ça me semble évident de faire des fonctions récursives lorsque certains traitements sont récursifs !!!

[Tober]

Le sens était: est-ce que vous en programmez souvent ?
Moi aussi elles tournent tous les jours vu que c'est des programmes en production...
Et si tes programmes en ont, c'est qu'ils doivent pas arriver à 600 de profondeur ?

[Hibernatus34]

Pas de possibilité de fixer la taille de la pile utilisée par l'exécutable.

La taille de la pile je l'ai modifiée une fois directement avec un éditeur hexa (cf. format PE), ça avait fonctionné. (en WD15)
Je pense qu'on doit pouvoir modifier le lanceur pour que tous les exe générés par WinDev aient la modif.
J'ai pas vérifié pour les threads en revanche.

Pas de projet de type Console.

C'est franchement pas le but de WinDev. La fonction Trace me suffit largement.

Exceptions et erreurs :
• les erreurs sont gérées différemment selon les groupes de fonctions; la gestion des erreurs manque d'homogénéité.
• les exceptions de niveau application sont identifiées par un n° compris entre 1 et 1000: c'est "l'âge de pierre" !
• impossible de déclencher des exceptions réservées par Windev (n° supérieur à 1000) pour simuler/provoquer des erreurs fatales (c'est un vrai besoin en particulier pour les tests ; ce n'est pas un gadget).

D'accord avec tout ça, et j'ajoute que certaines fonctions peuvent dans certains cas déclencher une exception alors qu'elles ne semblent pas le permettre. HAjoute nous a fait cette surprise avec une exception OLE DB, mais je ne me souviens plus dans quelle situation.

Programmation récursive :
La récursivité est bridée à une profondeur de 600 appels, on se demande bien pourquoi !

Une profondeur de 600 c'est franchement pas mal, surtout pour un langage dont on ne peut prédire l'empreinte mémoire. Je serais tenté de vous dire de faire une DLL ou de passer à de l'itératif.

Type de données Structure :
Impossible d'affecter aux membres une valeur par défaut.

C'est vrai que ça manque, sachant qu'il existe VariableRAZ, ça serait pratique.

Constantes :
impossible de les typer.

Elles sont plus proches d'un #define en C (remplacement par des valeurs immédiates à la compilation).

• Impossible de déclarer une variable statique.

Une statique locale c'est l'horreur. Une globale de collection de procédure ou de classe fera l'affaire.

• "Fausse bonne idée" des variables d'itération qu'il n'est pas nécessaire de déclarer. Pratique ? peut-être, mais rigoureux sûrement pas.

Questions:
(1) comment le compilateur devine-t-il le bon type de de données à utiliser ?
(2) (exemple vécu) en cas d'erreur de frappe, on se retrouve avec 2 variables: une première déclarée explicitement et une deuxième (celle avec une faute de frappe) déclarée "automatiquement".
Un bug de programmation difficile à détecter pour les débutants.

Pas d'accord du tout. Rien n'oblige à l'utiliser, mais c'est franchement mieux.
Le type, WinDev le déduit naturellement et ça évite justement que le développeur se trompe entre chaîne/entier/variant, entre référence à l'objet et copie de l'objet, etc.
Ca permet de limiter naturellement l'usage de la variable à la boucle, et de ne pas rendre le code inutilement long.
J'utilise ça tout le temps et je n'ai jamais eu de problème.

Fonctions bloquantes non-interruptibles :
par exemple les fonctions d'archivages, fonction HTTPRequête...
A défaut de les rendre interruptibles, un fonctionnement asynchrone pourrait être proposé.

D'accord pour l'interruptible, mais pour l'asynchrone, à vous de les lancer dans un thread. Pour ma part, le seul problème, c'est HExécuteRequête, car une source de donnée doit être parcourue dans le thread qui l'a créée.

[Nicolas_Jeanneau]

Le sens était: est-ce que vous en programmez souvent ?
Moi aussi elles tournent tous les jours vu que c'est des programmes en production...
Et si tes programmes en ont, c'est qu'ils doivent pas arriver à 600 de profondeur ?

Non en effet si j'ai 25-30 niveau d'appels, je dois être au max

Je ne vois pas ce qui peut engendrer un tel nombre d'appels (+ de 600) ...

[tatayo]

Pas d'accord du tout. Rien n'oblige à l'utiliser, mais c'est franchement mieux.
Le type, WinDev le déduit naturellement et ça évite justement que le développeur se trompe entre chaîne/entier/variant, entre référence à l'objet et copie de l'objet, etc.
Ca permet de limiter naturellement l'usage de la variable à la boucle, et de ne pas rendre le code inutilement long.
J'utilise ça tout le temps et je n'ai jamais eu de problème.

Le problème n'est pas que cette fonctionnalité existe, mais que rien ne permet de la bloquer.
J'ai pour habitude de déclarer toutes mes variables en début de traitement (reste de C, de Pascal... bref vieux papy tout ça ).
Le problème est que si on fait une faute de frappe sur le nom de la variable dans la boucle, on n'a pas d'erreur, mais le code ne fonctionne plus.
Exemple:

Code :

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

1
2
3
4
5
 
nMonCompteur est un entier
 
Pour nMnCompteur = 1 a 10
<div style="margin-left:40px">wl.trace(nMonCompteur)</div>FIN

Pas d'erreur, mais la trace ne renvoie que des 0.
S'il y avait une option dans WinDev pour forcer la déclaration des variables, ce ne serait pas un problème, mais un choix proposé au développeur.

Tatayo.

[Emmanuel Lecoester]

tatayo tu penses au mode explicite de VB ?

[Hibernatus34]

Le problème n'est pas que cette fonctionnalité existe, mais que rien ne permet de la bloquer.
J'ai pour habitude de déclarer toutes mes variables en début de traitement (reste de C, de Pascal... bref vieux papy tout ça ).
Le problème est que si on fait une faute de frappe sur le nom de la variable dans la boucle, on n'a pas d'erreur, mais le code ne fonctionne plus.
Exemple:

Code :

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

1
2
3
4
5
 
nMonCompteur est un entier
 
Pour nMnCompteur = 1 a 10
<div style="margin-left:40px">wl.trace(nMonCompteur)</div>FIN

Pas d'erreur, mais la trace ne renvoie que des 0.
S'il y avait une option dans WinDev pour forcer la déclaration des variables, ce ne serait pas un problème, mais un choix proposé au développeur

Oui, j'avais compris, mais franchement, c'est vous qui cherchez les problèmes en refusant de prendre les bonnes habitudes. De plus, vous avez la complétion et le surlignage.

Moi aussi je déclare toujours tout séparément du code, car dans WinDev, contrairement au C++, la portée au bloc n'existe pas... sauf pour les boucles justement !
Et là, c'est une bonne pratique de limiter la portée à la boucle.

Si on ne fait que des "POUR i = 1 A 42", il est normal d'y voir peu d'intérêt.
Mais ça :

Code :

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

1
2
3
4
5
POUR TOUT Elément, i DE MaStructure.MonTableau[nIndice].MonAutreTableau
    Elément.Numéro = i
    Elément.Donnée = ...
    ...
FIN

Je ne voudrais pas avoir à l'écrire avec l'ancienne syntaxe, à moins d'utiliser systématiquement une fonction dans la boucle.

Ici tout est clair et bien délimité. Et je ne me pose pas la question "est-ce que je peux déclarer une référence aux éléments de mon tableau ?".

Même en C on peut écrire for (int i..., depuis le C99 il me semble.

Et voici une petite illustration de la portée bloc :

[Hibernatus34]

Voici du code qui illustre l'incohérence qu'il y a à déclarer une variable et l'utiliser comme variable de boucle :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
nVal	est entier
nPtr	est entier système
tabVals	est tableau d'entiers	= [1, 2, 3, 4]
 
POUR TOUT nVal, i de tabVals
	nPtr = &nVal
	SI nPtr = &tabVals[i] ALORS
		Trace("nVal pointe sur tabVals[" + i + "] : " + NumériqueVersChaîne(nPtr, "X"))
	FIN
FIN
Trace("Dernière valeur accédée : " + nVal + ", adresse : " + NumériqueVersChaîne(&nVal, "X"))
nVal = 51
Trace("Dernière valeur du tableau après nVal = 51 : " + tabVals[TableauOccurrence(tabVals)])

En fait on n'a pas 1 variable, mais 2 choses : un alias dans la boucle, et une variable hors de la boucle, qui contiendra une copie de la dernière valeur accédée en sortie de boucle.

S'il fallait ajouter une option, ça serait plutôt un avertissement pour le cas où on a déclaré la variable.

[tatayo]

tatayo tu penses au mode explicite de VB ?

J'avoue que je n'ai pas touché à VB depuis une bonne vingtaine d'année...

Hibernatus:
Je ne cherche pas les problèmes, mais justement à les éviter:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Toto est une structure
...
FIN
TabListeToto est un tableau dynamique de Toto
Totocourant est un toto
 
pour tout element Totocourants de tablistetoto
Totocourant.col1 = xxx
fin

Même type de code, aucun avertissement, aucune erreur, un gros bug.

Je ne dis pas que cette fonctionnalité est une erreur, qu'il faut la supprimer. Je dis juste qu'il faudrait une option pour pouvoir la désactiver (comme celle concernant le dépassement d'indice avec les tableaux).

Personnellement je suis pour les langages déclaratif et typés (j'avoue que je m'accommode des conversion explicites, mais je m'en passerai aussi facilement. Mais c'est un autre débat.).


Tatayo.