Discussion :

[forca]

Bonjour,

Je suis actuellement dans une boite ou le SI est très imbriqués.

Certaines procédures (de collections de procédures partagées) font références à des objets dont la classe utilise de l'IHM (de fenêtre d'autres projets) ou des variables globales (d'autres projets)...

Bref cela génère des erreurs de compilation qui n’empêchent pas les applications de tourner mais qui rendent difficile la gestion des applications.

Savez vous s'il est possible de récupérer une collection de procédure mais en "isolant" certaines procédures afin de ne pas avoir les erreurs.

Explication :

J'ai un projet A et un projet B. Dans le projet A j'ai la fenêtre A1 et A2, dans le projet B j'ai les fenêtre B1 et B2.

J'ai une collection de procédure CP partagé entre les 2 projets, elle contient les procédure P1 et P2.

P1 fait référence à un tableau de B1, du coup cela crée des erreurs dans le projet A même si le projet A n'utilise pas la procédure P1.

Est-il possible de partager CP dans le projet A mais en excluant la procédure P1?

Ou bien je dois détricoter?

Merci, Bonne journée

[tatayo]

Bonjour,
Pour moi tout ceci prouve surtout qu'il y a un problème de logique ici.
Si une procédure, une classe... fait référence "en dur" à une fenêtre, les deux doivent être dans le même projet.
Ici la seule solution "propre" que je vois est de découper la collection de procédure en 3 parties:

1. La partie vraiment partagée, commune aux deux projets mais indépendante des 2 projets, qui finit dans un composant
2. La partie A dans le projet A
3. La partie B dans le projet B

Une autre solution est de passer les noms de fenêtre en paramètres aux procédures et autre classe, et d'utiliser des indirections dans la collection de procédure.

Tatayo.

[tbc92]

Remplacer fenetre_b1.table1 par {"fenetre_b1.table1", indChamp} etc

Ca me paraît un bon compromis, plutôt que vouloir tout réorganiser.

[medbouh]

Remplacer fenetre_b1.table1 par {"fenetre_b1.table1", indChamp} etc

Ca me paraît un bon compromis, plutôt que vouloir tout réorganiser.

L'indirection serai un bon compromis à court terme, sinon la solution de tatayo est à prendre en considération comme solution à moyen et long terme.

[tunizar]

Bonjour,

Je suis actuellement dans une boite ou le SI est très imbriqués.



Ou bien je dois détricoter?

Merci, Bonne journée

Bonjour,
Il est temps de passer en POO...

[forca]

Merci à tous pour vos réponses.

J'avais pensé à vos différentes solutions, mais une confirmation est positive.

J'ai déjà fait des indirections et je vais vais continuer quand c'est possible, logiquement plus personne ne fait ça.

Par contre il y a une procédure d'une collection de procédure qui fait appel à un objet qui n'est pas dans le projet que j'utilise, si j'importe l'objet, cela crée encore plus d'erreurs...

Dans ce cas là je vais prendre la solution de tatayo, voir si on peut déplacer cette procédure vers une autre collection ou la restreindre à un projet.

A moins que vous connaissiez une déclaration de variable par indirection!?

[forca]

Tunizar c'est déjà le cas mais on ne choisit pas de ce qu'on hérite!

On ne peux pas malheureusement tout redevelopper, en maintenant l'existant + les projets etc.

[tunizar]

Tunizar c'est déjà le cas mais on ne choisit pas de ce qu'on hérite!

On ne peux pas malheureusement tout redevelopper, en maintenant l'existant + les projets etc.

Bonjour,
La création d'une bibliothèque WDL qui se charge et décharge à la demande

[tbc92]

{mavar, indvariable}
Voir ici : http://doc.pcsoft.fr/fr-FR/?1512005

[forca]

Ca c'est pour y accéder mais au moment de la déclaration ?

Cas concret, déclaration d'une variable de type Obj_ext dans FG_Proc1 qui appartient à une classe de procédure partagée dans le projet P1 mais la classe Obj_ext n'appartient pas au projet P1.

Code :

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

1
2
PROCEDURE FG_Proc1()
gclObjExt est un objet Obj_ext dynamique

Je voudrais que soit la fonction FG_Proc1() ne soit plus pris en compte dans le projet P1 ou bien trouver une autre syntaxe de déclaration qui ne générera pas d'erreur dans le projet P1.

Merci

[Narwe]

Bonjour,

Pour éviter de compiler une partie du code selon la configuration, on peut utiliser la condition COMPILE SI
On définit le nom de la configuration au niveau de chaque projet.

[forca]

Merci à tous, grâce à la dernière solution de Narwe avec Compile SI et toutes les solutions vu avant je vais corriger nos problèmes.

Malheureusement je vais devoir attendre le passage en 21, nous ne sommes qu'en version 20.

[tunizar]

Bonjour,

Pour éviter de compiler une partie du code selon la configuration, on peut utiliser la condition COMPILE SI
On définit le nom de la configuration au niveau de chaque projet.

Bonjour,
Bonne idée !