Discussion :

[R&B]

Bonjour

Tous le monde connais la fonction Ouvre qui permet l'ouverture des fenêtres. C'est le prototypage de cette fenêtre qui me pose une petit problème, je cite :

[<Résultat> = ] Ouvre(<Nom de la fenêtre> [ , <Paramètre 1> [ , <Paramètre 2> [ , ... ]]])
...
<Nom de la fenêtre> : Chaîne de caractères (avec ou sans guillemets)

Dans un cas précis qui n'est pas le sujet de ce fil de discussion je dois ajouter des contrôles avant ouverture (et donc monter une forme de surcharge à cette fonction) avec la complétion et donc la syntaxe "sans guillemets". Évidemment, en exécution, l'erreur comme quoi "le champ <Nom de la fenêtre> n'existe pas" survient à juste titre vu que la fenêtre n'est pas ouverte.

Je ne vois pas comment lancer une forme de "Ouvre" avec la complétion.
L'idée est de ne pas avoir a remplacer le nom des fenêtres par des chaines : Le contrôle porte sur 250 occurrence au moins.

Information relative : on a les types, Source de données, procédure, champ qui permettent le transport des nom de fichier, de procédure et de champ qui répondent à ce besoin de complétion... mais rien pour les fenêtres.

[Hemgé]

Bonjour,

Si vous développiez un peu plus votre contexte, nous pourrions sans doute mieux prendre nos repères.

Pour ce que je saisis de votre problématique, je proposerais :
- soit d'ouvrir vos fenêtres à partir d'une procédure / composant ad-hoc qui gérerait les contrôles ;
- soit de gérer ces contrôles dans la procédure d'ouverture de la fenêtre, qui reçoit les paramètres.

La seconde proposition ne convient vraisemblablement pas à votre situation, sinon vous n'auriez sans doute pas ouvert le sujet.
Elle peut cependant être utilisée si les fenêtres en aval effectuent des traitements (quasi-)similaires sur des fichiers de structures identiques (ex, une série de fichiers de références), qu'on peut traiter à partir d'une seule fenêtre à condition de pouvoir paramétrer les fichiers-cibles.

Hemgé

[R&B]

Salut Hemgé.
Merci pour l'intérêt.

Pour en dire plus, c'est simple : il s'agit d'un menu (que ce soit en menu déroulant/ruban/boutons etc) fourni au moins 250 options pour ouvrir des fenêtres.
Nous devons effectuer des contrôles d'existences de ces fenêtres (FenEtat) pour soit empêcher leur ouverture ou forcer un changement de contexte d'utilisation.

- Je ne souhaite donc demander aux développeurs de copier 250 fois le code qui évalue la présence de la fenêtre pour déclencher l'interprétation.
- Je ne souhaite pas non plus mettre tous les noms de fenêtres dans des chaines pour la simple raison que la complétion assure aussi la maintenance du code. Renommer/supprimer une fenêtre utilisée dans ce menu engendrera un effet en compilation que l'utilisation d'une chaine occulte... en plus d'être un calvaire à mettre en place.

Les variables type Procédure et Champ qui permettre d'avoir un pointeur sur l'élément sont une réponse qui n'existe sur les fenêtres... sauf si quelqu'un a trouvé.
En résumé : Il ne nous est pas possible de produire une surcharge d'une fonction Ouvre avec la syntaxe sans guillemet.

Code idéal :

Code :

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

1
2
3
4
5
6
7
8
9
MaFen est une fenêtre = NomDeMafenêtreSansGuillemet
MonOuvre(MaFen) // procédure avec contrôle qui peut lancer FenEtat(), Ouvre() ou une autre forme d'ouverture... 
 
PROCEDURE MonOuvre(MaFen est une fenêtre)
SI FenEtat(MaFen) = Inexistant ALORS
   Ouvre(MaFen)
SINON
   // Autre comportement
FIN

[hpascal]

Bonjour

C'est bien ça, il manque le type "fenêtre"

J'ai été confronté au même problème et j'ai renoncé pour l'instant

A tout hasard pose la question au ST, on ne sait jamais (oui je rêve un peu)

[Ry_Yo]

Ce n'est pas la solution, mais un compromis faute de mieux il me semble...

Créer autant de constante que de fenêtre... (avec notepad++ ou autre outil on peut rapidement écrire ce bout de code)
Et passer par ces constantes pour les appels...
les + :
complétion
cohérence du nom de la fenêtre dans 1 seul point d'entrée, donc répercussion plus rapide en cas de changement de nom de fenêtre

les - :
en cas de création / modification du nom de la fenêtre ne pas oublier de mettre à jour la constante équivalente

EDIT : on peut même imaginer un truc plus tordu
A l'init du projet, on énumère toutes les fenêtres du projet et on construit un fichier texte contenant une syntaxe valide de WLangage pour déclarer les constantes à la volée.
Ensuite seulement on appel le fichier construit dynamiquement... Cela évitera d'oublier de rajouter ou modifier correctement toutes les fenêtres du projet. D'accord faudra faire au moins 1 "GO" avant de coder pour être sur d'être synchro...

[R&B]

Salut Ry_Yo et Merci Pascal.

En effet, c'est, à mon grand regret, la solutions vers laquelle nous cheminions en raison d'un usage ce cette 'liste' par ailleurs.
Le "Go" en mode test peut évaluer la date/heure/contenu d'un fichier .WL (dans lequel on peut spécialiser la déclaration des constantes d'appel de fenêtre et le reconstruire... vu que l'on ne génère aucun projet sans avoir lancé en mode test. Ensuite, il suffit de prévoir une règle de nommage pour ces constantes afin d'en disposer automatiquement.



Merci.

[madsland]

Bonjour,

J'ai lu le sujet en diagonale donc je suis peut être hors sujet mais avez-vous lu cela ?

http://blogs.pcsoft.fr/post.awp?titl...onctions,2,473

Cordialement

Madsl@nD

[Ry_Yo]

Yeah !
+1 madsland

je viens de tester, ça fonctionne au poil ce truc !
en entrée, on a l'impression de passer en paramètre l'objet fenêtre et dans la procédure, c'est une simple chaine contenant le nom de la fenêtre

Je pense que tu viens de sauver R&B ^^

[Hemgé]

J'ai probablement raté quelque chose, mais qu'est-ce qui vous empêche de travailler avec des variables ou éventuellement l'indirection et l'appel à une/des procédure(s) ?

Lorsqu'on sélectionne une option du menu, on affecte le nom de la fenêtre cible à une variable, en dur , ou via récupération dans la liste évoquée, éventuellement via le n° de l'option ou ...
Ensuite, on appelle une procédure qui reçoit le nom de la fenêtre sous forme d'une variable chaîne et l'utilise soit tel que (FenEtat, Ouvre etc), soit via l'indirection.
Des paramètres supplémentaires peuvent affiner le traitement.

[themayu]

Je viens d'essayer rapidement, mais pour déléguer l'ouverture d'une fenêtre, ça ne fonctionne pas malheureusement, ou alors j'ai les doigts palmés.

On a bien l'auto-complétion, mais il traite la fenêtre comme si on l'utilisait dans l'éditeur, par exemple pour accéder à un de ses membres, et si elle n'existe pas on a une belle erreur "Le champ .... est inconnu", normal, elle n'existe pas encore.

Dommage, ça avait l'air sympa !

Pour ce qui est de l'intérêt de l'auto-complétion, ça permet simplement à l'éditeur de détecter l'erreur si on change/supprime la cible, alors qu'avec une chaîne, on aura juste un beau message d'erreur quand on exécute.

[R&B]

Bravo madsland !!!!
La remarque de themayu doit simplement être conditionnée par l'évaluation de la présence en mémoire de l'élément comme je l'avais indiqué dans mon code... FenEtat()

Mais je confirme qu'avec le FenEtat, madsland m'a effectivement sauver :

Code :

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

1
2
3
4
5
6
7
8
9
MonOuvre(NomDeMafenêtreSansGuillemet) // procédure avec contrôle qui peut lancer FenEtat(), Ouvre() ou une autre forme d'ouverture... 

PROCEDURE MonOuvre(MaFen est une chaine <nom de fenêtre>)
SI FenEtat(MaFen) = Inexistant ALORS
   // la fenêtre n'est pas ouverte, aucun contrôle nécessaire
   Ouvre(MaFen)
SINON
   // Autre comportement
FIN

Ce code lance Autre Comportement si la fenêtre est déjà ouverte, et ouvre la fenêtre sinon...

Note pour moi-même :
1-Apprendre par coeur le contenu du blog du ST !
2-Réserver un cookie pour Madsland : gg !

[themayu]

Effectivement, je viens d'essayer dans un projet vide, avec une procédure globale pas de problèmes ...

Par contre, si on essaye avec une méthode de classe, ça ne fonctionne plus, le retour de "Champ .... inconnu"

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
######################
MaClasse est un classe
FIN
---------------------
PROCEDURE Fenêtre_ouvre(_Fenêtre est chaîne <nom de fenêtre>)
Ouvre(_Fenêtre)
######################
Dans un bouton d'une fenêtre :
pclTest est un MaClasse 
pclTest:Fenêtre_ouvre(FEN_MaFenêtre)

Donc que je dirais oui mais, en tout cas pour moi je ne peux pas l'utiliser, j'ai déjà une classe qui gère toutes mes fenêtre MDI, leurs onglets et leur option de ruban...

En tout cas ça répond à la demande R&B, donc bravo madsland !

[R&B]

Le FenEtat est obligatoire avant toute invocation de la fenêtre en paramètre, que ce soit en classe ou procédure et quelle qu'en soit la portée

Code :

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

1
2
3
4
5
6
7
8
9
10
11
######################
MaClasse est un classe
FIN
---------------------
PROCEDURE Fenêtre_ouvre(_Fenêtre est chaîne <nom de fenêtre>)
Si FenEtat(_Fenêtre)<>inexistant ALORS Ouvre(_Fenêtre)
######################
Dans un bouton d'une fenêtre :
pclTest est un MaClasse 
pclTest:Fenêtre_ouvre(FEN_MaFenêtre)

[hpascal]

Merci pour cette info très utile madsland
Comment as tu trouvé cette syntaxe ? par l'aide ou par un exemple pcsoft ?

EDIT : question débile : dans le blog de pcsoft vu que tu as mis le lien :-)

[themayu]

Si vous prenez le temps de tester l'exemple, vous constaterez que cela plante avant d'entrer dans la procédure, avant donc votre fenetat(), dans le code du bouton ...
S'il faut que le fenêtre soit ouverte pour pouvoir l'ouvrir, ça limite vraiment le concept ! mais bon, ça marche depuis autre chose qu'une classe, sans doute simplement un bug dans l'IDE

Pour la blague j'ai pris la peine de vous faire un petit projet de test

[hpascal]

Au pire si ça ne fonctionne pas dans les classes il faudra le signaler au ST

C'est déjà un grand pas de pouvoir le faire

Test concluant chez moi, la complétion propose immédiatement les fenêtres et j'ouvre bien la fenêtre dans la procédure appelée

[R&B]

Je confirme, themayu, en classe, cette syntaxe ne passe pas...
Mais en utilisant une procédure locale faisant référence à la classe je suis passé...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Option de menu
MenuOuvre(MaFenêtreSansGuillement)
 
// Procédure locale
PROCEDURE MenuOuvre(cFenêtre est une chaîne <nom de fenêtre>)
oMaClasse:MenuOuvre(cFenêtre)
 
// méthode de la classe
MenuOuvre(cFenêtre est une chaîne  <nom de fenêtre>)
SI FenEtat(cFenêtre)=Inexistant ALORS
	Ouvre(cFenêtre)
SINON
	// Autre comportement
FIN

[hpascal]

On fait comme on peut

[themayu]

On verra ce que dit le support technique, j'avais fait la requête dans le même temps ... mais c'est quand même vicieux comme bug, parce que y'a rien qui ressemble plus à une déclaration de procédure qu'une déclaration de procédure, dans une classe ......
Aller Windev 22 on aura un type fenêtre, on y est presque !

[R&B]

Je pense que le problème provient d'un découpage de l'espace de nom quand on passe en objet, d'où cette astuce.