Modifier variable public d'un autre formulaire: Form_Open (byval)

Version imprimable

Bonjour,

J'ai un formulaire F_Fichier (dont la source est vide) qui contient des liste déroulantes et des boutons.
C'est un formulaire que je souhaite utiliser comme sous formulaire d'un certains nombre d'autres formulaires.

L'ensemble du code de F_Fichier est basé sur 3 variables qui sont définies à l'ouverture du formulaire:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 Option Compare Database Option Explicit Public Affectation As Control, Nature As String, Mission as Control Private Sub Form_Open(Cancel As Integer) Nature = "'Données Récoltées'" Set Mission = Me.Parent.N°Mission Set Affectation = Me.Parent.N°Affectation End Sub
Je souhaiterai pouvoir modifier ces variables via un autre formulaire, afin de pouvoir ouvrir le formulaire plusieurs fois avec différentes variables?

Grossièrement, j'aurai vu quelque chose comme ça:

Code:

Public Form_Open(byval Nature as string, byval Affectation as control, byval Mission as Control)

Est-ce possible? ou y a t il d'autres manières de procéder?

merci

zkunk

15/08/2017, 03h18
Gfacro

Vous devriez pouvoir vous adresser aux autres formulaires par Forms("F_Fichier").Parent.N°Mission

Avez-vous essayé d'utiliser byref dans votre passage de paramètre ? Byval d'un control dans un autre control, je ne suis pas sur de ce que ça fait.

Avez-vous vérifier les tutoriels sur la portée des variables ? Il ne faudrait pas que la déclaration de vos variables globales soient dans un module général ?

Bonjour Gfacro,

Merci pour les pistes !!

J'ai donc déclaré les 3 variables dans un module
Code:

1 2 3 Option Compare Database Option Explicit Public Affectation As Control, Mission As Control, Nature As String
Créé une fonction dans un module qui permet d'affecté des valeurs à ces variables:
Code:

1 2 3 4 5 Function FichierFormSource(ByVal strNature As String, ByVal ctlMission As Control, ByVal ctlAffectation As Control) Nature = strNature Set Mission = ctlMission Set Affectation = ctlAffectation End Function
Il ne me reste plus qu'à appeler cette fonction (depuis n'importe ou) lorsque je veux changer la source:

Code:

Call FichierFormSource("'Données Traitées'", Me.Parent.F_Mission_Detail.Form.N°Mission, Me.Parent.F_Mission_Detail.Form.N°Affectation)

Je sais pas si c'est très académique, car les variables restent dans toute l'appli ! en tout cas ça marche !! :D
PS: je vais aller revoir un peu les cours sur byref et byval, car j'utilise bêtement byval tout le temps...
1) dans mon exemple je ne sais pas si il ne serait pas mieux d'utiliser des byref pour les control...
2) faut il a la fin de l'utilisation des variables définit avec "Set", vider les variables?

Merci et A+

zkunk

15/08/2017, 21h38
Gfacro
Lorsque vous aurez vérifié les tutoriels, vous pourrez corriger ce que je vais dire mais pour moi :

ByRef signie par reference=adresse mémoire : vous avez deux variables avec des noms differents qui adressent la même zone mémoire ou est stockée la valeur de la variable. Modifier la valeur d'une des deux variable modifie la valeur de l'autre. il y a des exemples dans des tutoriels pour le montrer des choses du genre
Code:

1 2 3 4 5 6 7 8 9 10 11 dim i as integeger i = 5 call addOne(i) msgbox i 'avec la procedure: sub addOne(nombre as intger) nombre = nombre+1 msgbox nombre end sub
et vous faites tourner cela en ajoutant devant nombre byref puis byval Vous pouvez vous amuser en declarant i global et en faisant varier i aussi, en declarant i dans addOne et en le faisant varier dedans aussi, ...
Le resultat me semble facile a comprendre

Dans votre cas, vous faisiez du byval sur un control.
Le control de départ est dans un formulaire, pas de souci, je le visualise bien.
Dans la procédure appelée, si je devine bien, la procédure appelée crée un control (une liste déroulante) qui n'a de propriété renseignée que celle de sa valeur - la valeur de la liste déroulante de départ. Il faut tester mais il est possible que ce nouveau control prenne toutes les valeurs de la liste de départ. Je pense néanmoins que ce n'est que la propriété values qui est renseignée. En tout cas les modifications que vous lui faites disparaissent avec la fin de la procédure.

De toute façon, quoi qu'il en soit, il ne faut jamais rien faire de systématique en informatique mais se dire que
*1) Si on a un choix, s'il y a un argument, c'est qu'un jour ou l'autre on sera amené théoriquement à avoir besoin de l'alternative et qu'il est donc utile de comprendre à quoi servent chaque mot d'un programme, de ce qu'on fait.
*2) Lorsqu'on n'a pas le résultat qu'on souhaite, chercher si on voit ce qui ne fonctionne pas et si on ne trouve pas - pour aller plus loin, commencer par vérifier ce qu'on ne maîtrise pas bien. Il m'est déjà souvent arrivé que les soucis ne soient pas situé là ou il y a une anomalie, un plantage, mais là où je n'ai pas maîtrisé ce que je faisais.

Pour ce qui est de vider la mémoire, j'avoue ne pas le faire personnellement assez. Je vous y engage toutefois, cela entre dans le processus de maîtrise de ce qu'on fait, de pourquoi on le fait, et cela permet d'affirmer qu'à partir de cet instant, on sait qu'on n'en a plus besoin. Maintenant, il est très rare qu'on aie des soucis de capacité des ordinateurs aussi cela devient de moins en moins problématique.

je pense que vous naviguez trop dans vos objets. Je ne sais pas comment sont vos formulaires, vos objets et vos variables.

Je vois dans votre code f_mission_detail. Est-ce un formulaire ? En ce cas, votre .form m'a l'air inutile puisque c'est déjà un formulaire.
Vos Me.parent, sont ils bien utiles ? Avez-vous essayé de faire simplement me pour voir si cela ne fonctionne pas aussi ?

pour l'académisme, ce n'est pas bien grave je pense. Il faudrait voire votre application pour savoir si c'est utile. En tout cas, vous semblez les utiliser à un endroit différent de celui ou vous les définissez aussi oui, cela a l'air judicieux.

Dans mon message précédent, je vois que j'ai parlé de Forms("F_Fichier").Parent.N°Mission, mais il est très possible que parent soit inutile dans l'appel