Application avec plusieurs autres sous-applis en Références

Question

Bonjour,

Cela fait plusieurs jours que je cherche désespérément sur le net de la doc sur les références vers d'autres databases mde, mais je trouve jamais rien de très poussé 

J'ai une application qui ouvre un menu principal avec une liste de nos dossiers, avec des filtres dès qu'un dossier est selectionner on on choisis par bouton les différens écrans de travail ou d'informations à leur sujet, plus d'autres boutons pour d'autres sous-menu pour des utilitaires et écran de stats. 

Le projet devient tellement volumineux et complexe que chaque fois qu'il faut ajouter d'autres fonctionnalités, ou modifier l'écran contenant les stats, créés et modifiés par mon collègue, cela devient compliqué pour tout recompilé, parfois c'est juste 1 petite modif par ci par là (en plus du casse-tête de savoir si on compile la bonne version ).

Alors mon idée était de séparer l'appli en plusieurs databases mde, donc que j'appelle des sous-applis.
J'ai donc une appli principale où les boutons de menus outils et celui des stats ouvrent les forms des autres sous-applis. Pour cela j'ai mis dans mon applis principale des Références vers les autres mde.
Voici une idée de comment:

AppMain ayant les références : 
->AppWrkScreen
->AppUtilities
->AppScoreBaord

Le problème est que je n'arrive pas à trouver comment on fait dans le cas où par ex. la sous-applis AppUtilities doit appeler une procédure ou fonction qui se trouve dans la sous-applis AppWrkScreen, ou même une procédure/fonction se trouvant dans un module de l'applis principale AppMain. 

De même pour les variables que j'ai mis déclarés dans une classe, comment faire, si je la met et la déclare dans AppMain, pour l'appeler dans les sous-applis. 

Alors j'ai constaté aussi que les Références ne sont pas lue de la même facon si l'on référence le mdb ou le mde. On dirait que comme le mde est compilé, le code est moins accessible. Tout comme les tables liées, je suis obligée de les dédoubler dans chaque sous-applis, selon que je les ouvrent via vba (DAO) ou requetes(queries).

J'espère avoir su expliquer mon problème et que vous pourrez m'aider, car je désespère vraiment  et cela me bloque pour pouvoir avancer proprement. 

Je vous remercie d'avance .

cs_Jack · Answer

Salut
Je ne suis pas fortiche en vb.Net, mais si tu sépares ton application en plusieurs, distinctes, tu ne peux plus communiquer avec les objets/procédures stockées dans l'application étrangère.
Si tu sépares ton appli en Classes, c'est un peu pareil, les classes ne peuvent pas communiquer horizontalement.
Le mieux étant de conserver tout dans le même projet et revoir son organisation.

Je ne vois pas pourquoi la compilation serait un problème : "savoir si on compile la bonne version" Que veux-tu dire ?

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

thanae · Answer

Merci jack pour ta réponse rapide.
Si je comprends bien, c'est pas prévus que l'on puisse les faires communiquer. Ca c'est bien encore du MS!  Pourquoi faire qu'on puisse appeler de haut en bas(structurellement): AppMain qui appelle une fonction/procédure ou un form qui se trouvent dans AppWrkScreen ex: WrkScreen.MaFonctionX mais pas de bas en haut:  AppWrkScreen appelerai une fonction venant de AppMain ex: Main.MaFonctionY.

Ok, bon, je continue alors à dédoubler mon code et mes tables.
Je ne vois pas pourquoi la compilation serait un problème : "savoir si on compile la bonne version" Que veux-tu dire ? 
Mon collègue s'occupe de la sous-applis AppScoreBaord (tout ce qui concerne les stats et repporting) et moi le reste, donc notamment AppMain. Comme AppMain contient les références, cela devient parfois un casse-tête de savoir quelle est la derniere version à recompiler  (dès qu'un mde référencé change, il faut recompilé la principale également).

cs_Jack · Answer

Si, tu peux prévoir ce genre de communication (des DLL par exemple, avec une appli fédératrice), mais ça se résumera à lancer des fonctions qui ne pourront porter que sur les objets interne à ce programme.
Si ton application se limite à :
- avoir un programme principal qui ne serve que de "menu lanceur" aux programmes externes A, B et C (...)
- que tes sous-applications se contentent de travailler avec leurs propres objets et que, par exemple, le programme A n'a pas besoin d'accéder aux composants de B ou C

Alors oui, tu peux imaginer cette structure.
Ton appli principale pouvant servir de "serveur COM" (*) et les sous-applis pouvant communiquer et se servir des fonctions de l'appli principale.
En .Net, je pense qu'il y a d'autres techniques que le COM.

(*) je ne suis plus sûr que ça s'appelle COM, j'ai un trou. Ce dont je parle est la structure utilisée par les moteurs Excel ou Word

Oui, la recompilation de l'ensemble est nécessaire car les identifications système (GUID) changent à chaque compilation : les références doivent donc elles-aussi changer.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

thanae · Answer

Ok, donc c'est pas pour mon applis, vu que la moitié d'entre elles doivent communiqués. 
Si, tu peux prévoir ce genre de communication (des DLL par exemple, avec une appli fédératrice), mais ça se résumera à lancer des fonctions qui ne pourront porter que sur les objets interne à ce programme. Ca j'y avais penser, vu que j'en ai qqs unes qui sont indépendantes, mais les dll doivent etre en langage C, que je connais pas, et je sais pas comment on fait pour déclarer un .bas.
Ton appli principale pouvant servir de "serveur COM" (*) et les sous-applis pouvant communiquer et se servir des fonctions de l'appli principale. Mais sinon, comment tu configure ca, sachant que je suis en Access 2003(je pense pas que c'est du .net).

thanae · Answer

Bon, comme j'ai un peu avancé dans mes recherches et je voulais faire partager, pour ceux à qui ca pourrait intéressé un jour, ce que j'ai trouvé concernant les problemes soumis.
Le problème est que je n'arrive pas à trouver comment on fait dans le cas où par ex. la sous-applis AppUtilities doit appeler une procédure ou fonction qui se trouve dans la sous-applis AppWrkScreen, ou même une procédure/fonction se trouvant dans un module de l'applis principale AppMain. 
Alors pour la communication entre applis, c'est tout bête (mais il fallait y penser) j'utilise maintenant dans l'application principale les modules qui contiennent les fonctions et procédures en "Public". Depuis les sous-applis je peu ainsi les appelées avec tout simplement: Application.Run "NomSub", "param1", "param2",...
'ou pour une fonction
x=Application.Run("NomSub", "param1", "param2",...)
Maintenant, c'est un choix de les mettres dans l'applis principal, si j'ai pas le choix que de la laisser dans la sous-applis, j'applique un nommage adapté, en indiquant dans le début du nom d'abord le nom de la référence applis, ainsi je distinct bien les procédures "Public".

De même pour les variables que j'ai déclarées dans une classe, comment faire, si je la met et la déclare dans AppMain, pour l'appeler dans les sous-applis.
Pour cela, j'ai donc mis aussi dans l'applis principale, la classe contenant mes variables globales, et les autres dans les sous-applis, pareil avec le meme systeme de nommage, que je rappelle à chaque sous-applis via une fonction "Public":

' Dans General Functions de la appli principale AppMain
Public mVar As New mVariables ' 1ere et unique fois à déclarer en New

Public Function MainTakeVar() As Object
Set MainTakeVar = mVar
End Function

' Dans General Functions de la sous-applis AppUtilities
Public mVar As Object
Public uVar As New uVariables ' 1ere et unique fois à déclarer en New

'Dans le 1er form que l'on ouvre de la sous-applis
Sub Form_Open(Cancel As Integer)
Set mVar = Application.Run("MainTakeVar")
...
End Sub

' Si besoin de la classe uVar dans une autre sous-applis, pareil:
'
' dans la sous-applis AppUtilities
Public Function UtilTakeVar() As Object
Set UtilTakeVar = uVar
End Function
' dans la sous-applis AppWrkScreen 
Public mVar As Object
Public uVar As Object
'Dans le 1er form 
Sub Form_Open(Cancel As Integer)
Set mVar = Application.Run("MainTakeVar")
Set uVar = Application.Run("UtilTakeVar")
...
End Sub
Attention de ne mettre qu'une seule fois "New" et si il y a eu des valeurs à donnés en "Get", bien le faire avant de la récupérer dans la sous-applis.

Voilà, c'est un peu complexe à mettre en place et de bien s'organiser, mais après ca fonctionne super bien.

Mais je reste ouverte à de meilleurs idées.

Application avec plusieurs autres sous-applis en Références

5 réponses

Votre réponse

Discussions similaires