Discussion :

[J0r_x]

Bonjour,

J'ai plusieurs projets qui ont des fenêtres en commun, j'utilise donc des bibliothèques externes pour éviter d'avoir des fenêtres en double.
Le soucis est que lorsque je recréé l'exécutable d'un des projets et que je l'exécute j'ai une erreur lorsque j'appel une fenêtre présente dans l'un des .WDL d'un autre projet, j'ai comme erreur "Une erreur système inattendue est survenue".
Quand je regarde à la ligne ou il y a l'erreur, c'est toujours à l'endroit ou il y a une procédure d'une classe commune à l'intégralité des projets.

Dés le moment ou je refait l'intégralité des exécutables des projets qui sont en communs il n'y a plus d'erreur.

J'ai essayé avec les bibliothèques externes et aussi avec les bibliothèques secondaires ou je décoche les classes accessible depuis les projets externes pour prendre en compte les classes de l'exécutable qui appel la bibliothèque mais rien y fait j'ai toujours des erreurs.

La solution de recréer les exécutables à chaque modification dans un projet est assez fastidieuse si quelqu'un a une solution je suis preneur.

Merci

[Lo²]

Salut,

J'utilise régulièrement ce système et également avec des classes.
Le côté négatif de cela est le débuggage

Lorsqu'une des bib ou l'exe principal est modifié, je ne compile que celui-ci et ça fonctionne très bien.

Il faut faire attention au nommage de classe mais je pense que c'est fait , dans le sens où si dans une bib, tu possèdes cToto et que dans une autre, tu as également cToto, l'exe ne prendra qu'une des 2 en compte (ordre de chargement ?).

Pour débugger, tu peux activer le log, pour ainsi récupérer l'ensemble des objets et leurs valeurs.

[J0r_x]

Chez moi ça ne marche pas

Le log ne m'apporte rien plus que je ne savais déjà, il bloque au niveau de l'appel d'une procédure d'une des classes, et je n'ai pas de raison.

[Lo²]

Alors éventuellement, peux-tu dans le projet de la bib, simuler l'utilisation de cette procédure avec les valeurs du log ?

[J0r_x]

C'est à dire ?

[Lo²]

Dans l'initialisation de mes projets qui sont ensuite compilés en bib, j'ai ce type de code :

Code :

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

1
2
3
4
5
6
SI EnModeTest() ALORS
	ChargeWDL("C:\Program Files\WMP\lib\GES0050.WDL")
	ChargeWDL("C:\Program Files\WMP\lib\GES0300.WDL")
	ChargeWDL("C:\Program Files\WMP\lib\GES0500.WDL")
...
FIN

Je charge toutes les bib nécessaires en mode test pour un fonctionnement autonome lors des tests.

Si par exemple, j'ai besoin d'utiliser une procédure d'une classe du style cMaClasse:maProc(pObj) qui prend en paramètre un objet, j'ajoute dans le code ci-dessus :

Code :

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

1
2
3
oObjetAutre est un "cMaClasseAutre"(paramètres du constructeur)
oObjet est un "cMaClasse"(paramètres du constructeur)
oObjet:maProc(oObjetAutre)

Je ne sais pas si je suis clair

[J0r_x]

Je ne pense qu'il y ai des soucis avec les paramètres de ma classe puisqu'une régénération de l'exécutable résout le problème.
Je pensais plutôt à un soucis de version au niveau de la classe, ou Windev serais perdu, ou un truc du style.

[Lo²]

Qu'entends-tu par version de classe ?

[J0r_x]

Version n'est pas le bon terme, mais comme c'est une classe partagé entre plusieurs projets, si il y a eu des modifications dans la classe, les bibliothèques ne l'ont pas eu par exemple.

[Lo²]

ok, j'avais bien compris dans ce sens

Par contre, ce que je ne comprend pas, c'est que si la classe partagée est modifiée, les autres bib ne l'ont pas ?

Je prends un exemple :
Tu as une Bib1 avec une classe1.
Les Bib2 et 3 utilisent la Bib1 pour accèder à la classe1.

Si tu modifies classe1, les autres bib auront également la modification, il te suffit de compiler la nouvelle version de la Bib1, non ?

[J0r_x]

Oui c'est bien ça.
Une procédure de la classe de Bib1 ne plantera pas, par contre la meme procédure de la classe de bib1 dans bib2 va planter.
Est-ce que j'utilise mal la création de bibliothèque ou autre chose je ne sais pas

[Lo²]

Ben, la génération d'une bib ne donne pas beaucoup de possibilité dans le paramétrage, à part cocher ou décocher les éléments que tu veux dans la bib, donc je ne pense pas que ce soit là.

Pour que Bib2 utilise Bib1, tu utilises un ChargeWDL(..) ?

[J0r_x]

Oui en l'occurrence c'est exe1 qui charge bib2 :p
Surtout que dans Bib2 il n y a pas les classes, elles sont dans exe2, elle doit forcément prendre celle de exe1

[Lo²]

je me paume un peu, tu as 2 exe ?

Pourrais-tu succinctement décrire la structure entre les exe et les bib ?

[J0r_x]

En gros comme application j'ai ça :
doccom.exe + fourniss.wdl + engagem.wdl
fourniss.exe + doccom.wdl
engagem.exe + doccom.wdl

En gros quand je refait l'exécutable de doccom, elle va planter dans les fenêtres de fourniss.wdl ou d'engagem.wdl si dedans il y a des appels de procédures de classe qui sont dans doccom.exe

Suis-je clair ?

[Lo²]

On va voir ça de suite ^^

L'application principale "doccom.exe" charge 2 bibs (fourniss.wdl + engagem.wdl) qui utilisent des classes de "doccom.exe", c'est ça ?

Ou est-ce que, en plus, chacune des bibs charge une bibliothèque "doccom.wdl" ?
Si c'est le cas, je pense que le problème vient de là.

Pour l'application finale, les fichiers "doccom.exe" et "doccom.wdl" sont 2 fichiers distincts, qui donne "doccom.wdl" vainqueur dans l'ordre de chargement et donc de l'accès à une ancienne version de la procédure modifiée.

[J0r_x]

En gros j'ai pas d'application principal.
J'ai une dizaine d'applications qui prennent des fenêtres par ci par là.
Les classes ne sont stockés que dans les .exe
Les .exe sont indépendants de leurs .WDL respectif, c'est à dire que Doccom.exe fonctionne sans Doccom.WDL (Bibliothèque secondaire) qui ne sert que pour les applications qui en ont besoin.

[Lo²]

ok, n'as-tu pas le cas de figure de "doccom.exe" qui charge "fourniss.wdl", qui lui-même charge "doccom.wdl" ?
D'où le pourquoi il te faudrait compiler les exe et les bibs à chaque fois.

[J0r_x]

Le chargement des .WDL se fait dans le code d'initialisation du projet, qui ne doit pas être exécuté, enfin je pense puisque dans les .WDL puisqu'il n'y a que des fenêtres, états et les procédure globales.

[Lo²]

En effet, le code d'initilisation du projet n'est pas exécuté dans les WDL.

A part le fait, que j'aurai plutôt externalisé tous les éléments communs/utilisables par les exécutables et ainsi évité d'avoir à compiler un projet en EXE et en WDL, je ne vois plus trop où chercher

Par contre, un tout petit avis, je pense malgré tout qu'il faut se pencher du côté de ses différents appels de EXE utilisé en WDL et vice versa