Je travaille avec une feuille MDI parent, dans cette=20
feuille j'ai deux menu un menu ouvrir (qui me permet=20
d'ouvrir des objets d=E9ja cr=E9=E9 par le deuxi=E8me=20
menu 'cr=E9er')
Je voudrais quand j'ai cr=E9=E9 un nouvel objet par le=20
programme, mettre =E0 jour la zone de liste ouverte par le=20
menu ouvrir quand je quite le menu cr=E9er.
Je m'explique j'ai une feuille MDI parent son nom est=20
frmBudget. Sur cette feuille j'ai un menu mnuOpen qui=20
m'affiche une liste cboCpt, dans laquelle je choisi un=20
compte, quand je clique sur ce compte, il lance une=20
feuille fille et me permet de faire des op=E9rations sur ce=20
compte.
Par le menu cr=E9er je peux cr=E9er un nouveau compte. Jusque=20
la tout ce passe bien, mais je voudrais que la liste=20
cboCpt soit mise =E0 jour d=E8s que je cr=E9e un nouveau compte.
Je ne parviens pas a trouver la syntaxe me permettant =E0=20
partir du menu cr=E9er se touvant sur la feuille budget=20
(mdiparent) =E0 mettre la liste cboCpt lanc=E9e par le menu=20
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essay=E9 comme avant en VB5.0 frmbudget!cboCpt.additem
("valeur") mais cela ne marche pas.
j'ai essay=E9 me.frmbudget.cboCpt.additem("valeur")
Rien =E0 faire je n'arrive pas =E0 trouver la syntaxe,=20
quelqu'un pourrait-il m'aider j'ai pass=E9 en revue tout le=20
forum je n'ai pas trouv=E9 ou alors pas compris (je suis=20
novice en vb.net)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Zazar
Bonjour,
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!cboCpt.additem ("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois : faîtes une recherche dans les archives.
-- Zazar
Bonjour,
Je ne parviens pas a trouver la syntaxe me permettant à
partir du menu créer se touvant sur la feuille budget
(mdiparent) à mettre la liste cboCpt lancée par le menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!cboCpt.additem
("valeur") mais cela ne marche pas.
j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois : faîtes une recherche
dans les archives.
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!cboCpt.additem ("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois : faîtes une recherche dans les archives.
-- Zazar
André
Je sais mais je ne trouve pas ...
-----Message d'origine----- Bonjour,
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois :
faîtes une recherche
dans les archives.
-- Zazar
.
Je sais mais je ne trouve pas ...
-----Message d'origine-----
Bonjour,
Je ne parviens pas a trouver la syntaxe me permettant à
partir du menu créer se touvant sur la feuille budget
(mdiparent) à mettre la liste cboCpt lancée par le menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas.
j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois :
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Cette question a déjà été posée de nombreuses fois :
faîtes une recherche
dans les archives.
-- Zazar
.
Zazar
> Je sais mais je ne trouve pas ...
ok.
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un object b de type B et qu'on veut que a fasse une action sur b, c'est qu'il faut que a connaisse b. En vb6 ou antérieur, connaître le nom du type B suffisait. Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B) end sub L'objet de type a contient alors une référence vers l'objet de type B, et il peut donc le manipuler à volonté sous condition que B expose bien les méthodes publiques nécessaires à A (au hasard, une méthode pour ajouter un élément à une liste).
Petite amélioration : si on est sûr que a devra se servir de b, on peut créer un constructeur de A qui prend en paramètre un objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme approche : le code n'est pas réutilisable et tout changement dans la classe B va devoir être répercuté sur la classe A. Pour éviter ce problème, on va se poser la question : qu'est ce A a besoin de connaître de B ? Une fois qu'on a la réponse, on crée une interface I, on fait implémenter I par B, et au lieu de passer B à A, on lui passe un I. Et le tour est joué!
Voilà pour le cas général, essayez maintenant de le mettre en pratique dans votre situation et revenez si vous rencontrez des problèmes. Bon courage,
-- Zazar
> Je sais mais je ne trouve pas ...
ok.
Je ne parviens pas a trouver la syntaxe me permettant à
partir du menu créer se touvant sur la feuille budget
(mdiparent) à mettre la liste cboCpt lancée par le menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas.
j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un object b de type B
et qu'on veut que a fasse une action sur b, c'est qu'il faut que a connaisse
b.
En vb6 ou antérieur, connaître le nom du type B suffisait.
Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B)
end sub
L'objet de type a contient alors une référence vers l'objet de type B, et il
peut donc le manipuler à volonté sous condition que B expose bien les
méthodes publiques nécessaires à A (au hasard, une méthode pour ajouter un
élément à une liste).
Petite amélioration : si on est sûr que a devra se servir de b, on peut
créer un constructeur de A qui prend en paramètre un objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme approche : le code
n'est pas réutilisable et tout changement dans la classe B va devoir être
répercuté sur la classe A. Pour éviter ce problème, on va se poser la
question : qu'est ce A a besoin de connaître de B ?
Une fois qu'on a la réponse, on crée une interface I, on fait implémenter I
par B, et au lieu de passer B à A, on lui passe un I. Et le tour est joué!
Voilà pour le cas général, essayez maintenant de le mettre en pratique dans
votre situation et revenez si vous rencontrez des problèmes.
Bon courage,
Je ne parviens pas a trouver la syntaxe me permettant à partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le menu open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un object b de type B et qu'on veut que a fasse une action sur b, c'est qu'il faut que a connaisse b. En vb6 ou antérieur, connaître le nom du type B suffisait. Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B) end sub L'objet de type a contient alors une référence vers l'objet de type B, et il peut donc le manipuler à volonté sous condition que B expose bien les méthodes publiques nécessaires à A (au hasard, une méthode pour ajouter un élément à une liste).
Petite amélioration : si on est sûr que a devra se servir de b, on peut créer un constructeur de A qui prend en paramètre un objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme approche : le code n'est pas réutilisable et tout changement dans la classe B va devoir être répercuté sur la classe A. Pour éviter ce problème, on va se poser la question : qu'est ce A a besoin de connaître de B ? Une fois qu'on a la réponse, on crée une interface I, on fait implémenter I par B, et au lieu de passer B à A, on lui passe un I. Et le tour est joué!
Voilà pour le cas général, essayez maintenant de le mettre en pratique dans votre situation et revenez si vous rencontrez des problèmes. Bon courage,
-- Zazar
André
Merci pour votre aide, je vais essayer
-----Message d'origine-----
Je sais mais je ne trouve pas ...
ok.
Je ne parviens pas a trouver la syntaxe me permettant
à
partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le
menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un
object b de type B
et qu'on veut que a fasse une action sur b, c'est qu'il
faut que a connaisse
b. En vb6 ou antérieur, connaître le nom du type B
suffisait.
Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B) end sub L'objet de type a contient alors une référence vers
l'objet de type B, et il
peut donc le manipuler à volonté sous condition que B
expose bien les
méthodes publiques nécessaires à A (au hasard, une
méthode pour ajouter un
élément à une liste).
Petite amélioration : si on est sûr que a devra se
servir de b, on peut
créer un constructeur de A qui prend en paramètre un
objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme
approche : le code
n'est pas réutilisable et tout changement dans la classe
B va devoir être
répercuté sur la classe A. Pour éviter ce problème, on
va se poser la
question : qu'est ce A a besoin de connaître de B ? Une fois qu'on a la réponse, on crée une interface I, on
fait implémenter I
par B, et au lieu de passer B à A, on lui passe un I. Et
le tour est joué!
Voilà pour le cas général, essayez maintenant de le
mettre en pratique dans
votre situation et revenez si vous rencontrez des
problèmes.
Bon courage,
-- Zazar
.
Merci pour votre aide, je vais essayer
-----Message d'origine-----
Je sais mais je ne trouve pas ...
ok.
Je ne parviens pas a trouver la syntaxe me permettant
à
partir du menu créer se touvant sur la feuille budget
(mdiparent) à mettre la liste cboCpt lancée par le
menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas.
j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un
object b de type B
et qu'on veut que a fasse une action sur b, c'est qu'il
faut que a connaisse
b.
En vb6 ou antérieur, connaître le nom du type B
suffisait.
Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B)
end sub
L'objet de type a contient alors une référence vers
l'objet de type B, et il
peut donc le manipuler à volonté sous condition que B
expose bien les
méthodes publiques nécessaires à A (au hasard, une
méthode pour ajouter un
élément à une liste).
Petite amélioration : si on est sûr que a devra se
servir de b, on peut
créer un constructeur de A qui prend en paramètre un
objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme
approche : le code
n'est pas réutilisable et tout changement dans la classe
B va devoir être
répercuté sur la classe A. Pour éviter ce problème, on
va se poser la
question : qu'est ce A a besoin de connaître de B ?
Une fois qu'on a la réponse, on crée une interface I, on
fait implémenter I
par B, et au lieu de passer B à A, on lui passe un I. Et
le tour est joué!
Voilà pour le cas général, essayez maintenant de le
Je ne parviens pas a trouver la syntaxe me permettant
à
partir du menu créer se touvant sur la feuille budget (mdiparent) à mettre la liste cboCpt lancée par le
menu
open se trouvant lui aussi sur la feuille mdiparent.
J'ai essayé comme avant en VB5.0 frmbudget!
cboCpt.additem
("valeur") mais cela ne marche pas. j'ai essayé me.frmbudget.cboCpt.additem("valeur")
Alors le principe, quand on a un objet a de type A et un
object b de type B
et qu'on veut que a fasse une action sur b, c'est qu'il
faut que a connaisse
b. En vb6 ou antérieur, connaître le nom du type B
suffisait.
Sous .NET, il faut passer l'objet b à l'objet a.
Première méthode : créer une méthode dans la classe A
public sub SetObjectB(b as B) end sub L'objet de type a contient alors une référence vers
l'objet de type B, et il
peut donc le manipuler à volonté sous condition que B
expose bien les
méthodes publiques nécessaires à A (au hasard, une
méthode pour ajouter un
élément à une liste).
Petite amélioration : si on est sûr que a devra se
servir de b, on peut
créer un constructeur de A qui prend en paramètre un
objet de type B.
Ca c'est le cas de base mais ce n'est pas génial comme
approche : le code
n'est pas réutilisable et tout changement dans la classe
B va devoir être
répercuté sur la classe A. Pour éviter ce problème, on
va se poser la
question : qu'est ce A a besoin de connaître de B ? Une fois qu'on a la réponse, on crée une interface I, on
fait implémenter I
par B, et au lieu de passer B à A, on lui passe un I. Et
le tour est joué!
Voilà pour le cas général, essayez maintenant de le
mettre en pratique dans
votre situation et revenez si vous rencontrez des
problèmes.
Bon courage,
-- Zazar
.
Patrick Philippot
Zazar wrote:
Alors le principe, quand on a un objet a de type A et un object b de type B et qu'on veut que a fasse une action sur b, c'est qu'il faut que a connaisse b. En vb6 ou antérieur, connaître le nom du type B suffisait. Sous .NET, il faut passer l'objet b à l'objet a.
Bonjour,
Pour compléter cette excellente explication, j'ajouterai ceci. En VB6, les manipulations que vous décrivez sont réalisables parce qu'il est possible de déclarer des variables gobales ou parce que VB6 traite certaines données comme des variables globales. En .Net, vous êtes dans un environnement purement objet et il n'y a donc plus de notion de procédures globales ou de variables globables (même si la notion de module persiste mais ce n'est qu'un leurre - de manière sous-jacente VB .Net crée des classes pour les procédures déclarées dans des modules).
Si vous prenez ce point en compte, vous vous rendrez compte que vous devez passer, comme le décrit zazar, les informations nécessaires d'un objet à l'autre. Cela peut paraître une contrainte nouvelle mais c'est au contraire un moyen de produire des designs plus souples et plus faciles à maintenir.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Zazar wrote:
Alors le principe, quand on a un objet a de type A et un object b de
type B et qu'on veut que a fasse une action sur b, c'est qu'il faut
que a connaisse b.
En vb6 ou antérieur, connaître le nom du type B suffisait.
Sous .NET, il faut passer l'objet b à l'objet a.
Bonjour,
Pour compléter cette excellente explication, j'ajouterai ceci. En VB6,
les manipulations que vous décrivez sont réalisables parce qu'il est
possible de déclarer des variables gobales ou parce que VB6 traite
certaines données comme des variables globales. En .Net, vous êtes dans
un environnement purement objet et il n'y a donc plus de notion de
procédures globales ou de variables globables (même si la notion de
module persiste mais ce n'est qu'un leurre - de manière sous-jacente VB
.Net crée des classes pour les procédures déclarées dans des modules).
Si vous prenez ce point en compte, vous vous rendrez compte que vous
devez passer, comme le décrit zazar, les informations nécessaires d'un
objet à l'autre. Cela peut paraître une contrainte nouvelle mais c'est
au contraire un moyen de produire des designs plus souples et plus
faciles à maintenir.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Alors le principe, quand on a un objet a de type A et un object b de type B et qu'on veut que a fasse une action sur b, c'est qu'il faut que a connaisse b. En vb6 ou antérieur, connaître le nom du type B suffisait. Sous .NET, il faut passer l'objet b à l'objet a.
Bonjour,
Pour compléter cette excellente explication, j'ajouterai ceci. En VB6, les manipulations que vous décrivez sont réalisables parce qu'il est possible de déclarer des variables gobales ou parce que VB6 traite certaines données comme des variables globales. En .Net, vous êtes dans un environnement purement objet et il n'y a donc plus de notion de procédures globales ou de variables globables (même si la notion de module persiste mais ce n'est qu'un leurre - de manière sous-jacente VB .Net crée des classes pour les procédures déclarées dans des modules).
Si vous prenez ce point en compte, vous vous rendrez compte que vous devez passer, comme le décrit zazar, les informations nécessaires d'un objet à l'autre. Cela peut paraître une contrainte nouvelle mais c'est au contraire un moyen de produire des designs plus souples et plus faciles à maintenir.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
