Selection d'un BindingSource dans un autre formulaire depuis le concepteur

Bonjour,

On va dire que je suis semi-débutant ...
Pendant les vacances, autant que je m'y colle :)

Au départ, si on veut accéder à un objet depuis un autre module (ou
formulaire) que celui où il est défini, il faudra lui affecter le
modificateur qui va bien pour en donner la visibilité voulue, par
exemple public. On fera ça dans le code, donc le nom de fichier se
termine par designer.cs

Une chose m'intrigue, c'est que les déclarations se trouvent souvent à
la fin du designer.cs, alors que je me serais attendu à les trouver au
début (euh, en haut de la fenêtre, quoi ... et je les trouve en bas)

On ajoutera donc public devant par exemple
System.Windows.Forms.BindingSource tabActionBindingSource;
(bien sûr, public va remplacer private, le cas échéant)

Une fois qu'on a fait ça, dans le module appelant, on va préfixer le nom
de l'objet avec celui du module où il se trouve, par exemple Form1, on
dira donc Form1.tabActionBindingSource, d'ailleurs l'Intellisense
devrait même faciliter la manœuvre.

Le principal intérêt que je voie à faire ça plutôt que recrée r l'objet
sur le nouveau formulaire, c'est d'éviter que la base soit verrouillé e
par le premier formulaire pendant que le deuxième l'appelle. D'ailleurs
j'indique le principe, et je dois honnêtement préciser que je n'ai pa s
eu l'occasion de tester ce que je dis, de vérifier par exemple si une
DataGrid acceptera un objet préfixé comme propriété DataSource.

D'ailleurs, pour sortir un peu du sujet, si j'appelle un formulaire à
partir d'un autre et que le formulaire appelé doit modifier le
formulaire appelant, je fais quelque chose du même style -au passage si
quelqu'un a une meilleure idée je prends note :
- Form1 doit ouvrir Form2, qui modifiera une variable Texte dans Form1.
- Form2 comporte une variable
public Form1 frm1;
- Form1 effectuera l'appel comme suit :
Form2 frm2 = new Form2();
frm2.frm1 = this;
frm2.Show();
- lorsque la saisie a été faite dans frm2, il sera facile de
transférer la valeur dans le formulaire appelant ainsi :
frm1.Texte = ZoneTexte.Text;
this.Close();


Par ailleurs, histoire d'en revenir aux appels à une base de données,
quand il y aura de nouveau du monde ici, on pourra discuter de l'intérê t
de créer une classe spécialement pour les appels à la base, afin
d'éviter que le code correspondant reste chargé dans le formulaire,
lorsque le traitement consiste la plupart du temps à afficher les
données, et donc que l'accès à la base dure peu de temps, et qu'il peut
donc être intéressant que le code d'accès à la base ne reste pas
longtemps en mémoire. Enfin bon, ça, on ne va peut-être pas en disc uter
trop longtemps entre débutants :)


____________________________________
cc.18 a écrit, le 28/07/2009 12:34 :

Bonjour,
Je suis débutant en c#.
J'ai un dataset relié à une base de donner SQL Server, Sur un
formulaire, j'ai mon dataset, un table adapter et un bindingsource, ave c
tous ceci, j'arrive bien a lire modifier ma base.
Je creer un deuxieme formulaire ou j'insere un dataGridView, comment j e
peux selectionner ( pour la proprieté DataSource) mon BindingSource d u
formulaire precedent.
Je ne sais pas si je suis claire, en gros, je voudrais pouvoir avoir
acces au composant d'un formulaire dans un autre formulaire et pourvoir
les selectionner dans la fenetre de propriété.

Merci d'avance pour vos réponses.

/Dans son message précédent, _Gloops_ a écrit/ :

Bonjour,

On va dire que je suis semi-débutant ...
Pendant les vacances, autant que je m'y colle :)

Au départ, si on veut accéder à un objet depuis un autre module (ou
formulaire) que celui où il est défini, il faudra lui affecter le
modificateur qui va bien pour en donner la visibilité voulue, par exemple
public. On fera ça dans le code, donc le nom de fichier se termine par
designer.cs

ça, tu peux le faire directement dans la fenêtre d'édition des
propriétés

--
*/Teträm/*
http://www.tetram.org

"Fous-y sur la gueule, ça te mettra de bonne humeur" - Proverbe Troll

/_Gloops_ a pensé très fort/ :

D'ailleurs, pour sortir un peu du sujet, si j'appelle un formulaire à partir
d'un autre et que le formulaire appelé doit modifier le formulaire appelant,
je fais quelque chose du même style -au passage si quelqu'un a une meilleure
idée je prends note :
- Form1 doit ouvrir Form2, qui modifiera une variable Texte dans Form1.
- Form2 comporte une variable
public Form1 frm1;
- Form1 effectuera l'appel comme suit :
Form2 frm2 = new Form2();
frm2.frm1 = this;
frm2.Show();
- lorsque la saisie a été faite dans frm2, il sera facile de transférer la
valeur dans le formulaire appelant ainsi :
frm1.Texte = ZoneTexte.Text;
this.Close();

pour ça, s'il s'agit seulement d'informer form1 d'un evenement
particulier qui se passe dans form2, on preferera utiliser un système
d'event, plutôt que de donner une référence à form1

l'intérêt:
- permet d'indiquer d'autre form que form1: si plus tard, par exemple,
form3 ouvre aussi form2, elle pourra aussi bien être informée
- plusieurs fenêtres différentes (form1 et form3) pourront être
informée.... _en même temps_

et si c'est un peu plus complexe qu'être informé d'un evenement, dans
ce cas, il est préférable d'utiliser une interface: on garde au moins
le premier intérêt de l'event

--
*/Teträm/*
http://www.tetram.org

« Chérie, viens à table, le murloc va refroidir ! »

Merci de ta reponse,
J'ai essayer de mettre en public mon bindingSource du formulaire A, mais
je ne peux pas le selectionner dans mon dataGridView , proprieté Datasource
qui se trouve sur mon formulaire B ( en conception ).
Je viens du monde de Delphi, je crois que toi aussi, il n'y avais pas de
souci comme ca.
Encore une petite question si tu connais la réponse, y a t'il un moyen de
mettre en readonly le bindingSource pour mettre tous les controles associés
en readonly.

Pour la modif d'un label d'une form a une autre, moi j'utilise ca .

Dans form A : un Label1en public

Appel de form B depuis form A
Form FormB = new FormB() ;
FormB.show(this) ;

Dans FormB :
((FormA)Owner).Label1.Text = "toto";

C'est quoi la meilleur solution ??

Et bonne vacance a toi.



"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de
news:uJ4MvG%23DKHA.1540@TK2MSFTNGP02.phx.gbl...
Bonjour,

On va dire que je suis semi-débutant ...
Pendant les vacances, autant que je m'y colle :)

Au départ, si on veut accéder à un objet depuis un autre module (ou
formulaire) que celui où il est défini, il faudra lui affecter le
modificateur qui va bien pour en donner la visibilité voulue, par
exemple public. On fera ça dans le code, donc le nom de fichier se
termine par designer.cs

Une chose m'intrigue, c'est que les déclarations se trouvent souvent à
la fin du designer.cs, alors que je me serais attendu à les trouver au
début (euh, en haut de la fenêtre, quoi ... et je les trouve en bas)

On ajoutera donc public devant par exemple
System.Windows.Forms.BindingSource tabActionBindingSource;
(bien sûr, public va remplacer private, le cas échéant)

Une fois qu'on a fait ça, dans le module appelant, on va préfixer le nom
de l'objet avec celui du module où il se trouve, par exemple Form1, on
dira donc Form1.tabActionBindingSource, d'ailleurs l'Intellisense
devrait même faciliter la manœuvre.

Le principal intérêt que je voie à faire ça plutôt que recréer l'objet
sur le nouveau formulaire, c'est d'éviter que la base soit verrouillée
par le premier formulaire pendant que le deuxième l'appelle. D'ailleurs
j'indique le principe, et je dois honnêtement préciser que je n'ai pas
eu l'occasion de tester ce que je dis, de vérifier par exemple si une
DataGrid acceptera un objet préfixé comme propriété DataSource.

D'ailleurs, pour sortir un peu du sujet, si j'appelle un formulaire à
partir d'un autre et que le formulaire appelé doit modifier le
formulaire appelant, je fais quelque chose du même style -au passage si
quelqu'un a une meilleure idée je prends note :
- Form1 doit ouvrir Form2, qui modifiera une variable Texte dans Form1.
- Form2 comporte une variable
public Form1 frm1;
- Form1 effectuera l'appel comme suit :
Form2 frm2 = new Form2();
frm2.frm1 = this;
frm2.Show();
- lorsque la saisie a été faite dans frm2, il sera facile de
transférer la valeur dans le formulaire appelant ainsi :
frm1.Texte = ZoneTexte.Text;
this.Close();


Par ailleurs, histoire d'en revenir aux appels à une base de données,
quand il y aura de nouveau du monde ici, on pourra discuter de l'intérêt
de créer une classe spécialement pour les appels à la base, afin
d'éviter que le code correspondant reste chargé dans le formulaire,
lorsque le traitement consiste la plupart du temps à afficher les
données, et donc que l'accès à la base dure peu de temps, et qu'il peut
donc être intéressant que le code d'accès à la base ne reste pas
longtemps en mémoire. Enfin bon, ça, on ne va peut-être pas en discuter
trop longtemps entre débutants :)


____________________________________
cc.18 a écrit, le 28/07/2009 12:34 :

Bonjour,
Je suis débutant en c#.
J'ai un dataset relié à une base de donner SQL Server, Sur un formulaire,
j'ai mon dataset, un table adapter et un bindingsource, avec tous ceci,
j'arrive bien a lire modifier ma base.
Je creer un deuxieme formulaire ou j'insere un dataGridView, comment je
peux selectionner ( pour la proprieté DataSource) mon BindingSource du
formulaire precedent.
Je ne sais pas si je suis claire, en gros, je voudrais pouvoir avoir
acces au composant d'un formulaire dans un autre formulaire et pourvoir
les selectionner dans la fenetre de propriété.

Merci d'avance pour vos réponses.

Faust a écrit, le 29/07/2009 07:21 :

/_Gloops_ a pensé très fort/ :

D'ailleurs, pour sortir un peu du sujet, si j'appelle un formulaire à
partir d'un autre et que le formulaire appelé doit modifier le
formulaire appelant, je fais quelque chose du même style -au passage
si quelqu'un a une meilleure idée je prends note :
- Form1 doit ouvrir Form2, qui modifiera une variable Texte dans For m1.
- Form2 comporte une variable
public Form1 frm1;
- Form1 effectuera l'appel comme suit :
Form2 frm2 = new Form2();
frm2.frm1 = this;
frm2.Show();
- lorsque la saisie a été faite dans frm2, il sera facile de
transférer la valeur dans le formulaire appelant ainsi :
frm1.Texte = ZoneTexte.Text;
this.Close();

pour ça, s'il s'agit seulement d'informer form1 d'un evenement
particulier qui se passe dans form2, on preferera utiliser un système
d'event, plutôt que de donner une référence à form1

Ah oui sur le principe du délégué ...
Je vais tâcher de me mijoter un exemple, avant j'ai du taf sur les donn ées.

Merci.

cc.18 a écrit, le 29/07/2009 10:09 :

Merci de ta reponse,
J'ai essayer de mettre en public mon bindingSource du formulaire A,
mais je ne peux pas le selectionner dans mon dataGridView , proprieté
Datasource qui se trouve sur mon formulaire B ( en conception ).

Je redoutais un peu quelque chose comme ça, ce n'est pas pour rien que
je précisais ne pas avoir essayé.
Si j'ai bien capté ce que dit Faust on peut rendre le contrôle public
depuis la fenêtre des propriétés (propriété Modifiers, ça m'i ntrigue
d'ailleurs que ce nom soit au pluriel), ça OK, après, pour appeler le s
données depuis une DataGrid sur un autre formulaire ...
Bon, si ce que j'ai avancé était une fausse piste, peut-être reste- t-il
à créer une classe d'accès aux données, pour pouvoir l'utiliser d epuis
plusieurs formulaires ?
Ou rendre public le DataSet ouvert sur un formulaire pour pouvoir le
parcourir sur un autre -pas la peine que la fenêtre des propriétés
permette de le rendre public si c'est pour ne pas s'en servir. Bon enfin
là c'est les grands principes, parce que je viens quand même de jeter un
coup d'œil, au niveau d'une DataGridView, j'ai accès aux DataSet du
projet, mais pas aux instances créées sur un formulaire. ça ne ré sout
donc pas la question du verrouillage.

C'est certainement une question bateau à laquelle quelqu'un a déjà dû se
frotter, on en saura sûrement plus quand il reviendra de la plage, ou
sur codes-sources, à l'adresse csharpfr.com, il va bien y avoir un
exemple. Même si un certain nombre des projets publiés sont méchamm ent
bugués, ça ne les empêche pas de répondre à des questions qu'on se pose.

J'ai déjà un certain nombre d'exercices à faire sur les données a vec un
seul formulaire, ceux avec deux je m'y colle après. Pas s'impatienter,
j'ai devant moi le chapitre de la DataGrid, avec les formats, les
modifications en verrouillant la clef, et quelques joyeusetés de ce sty le.

Pour ma part il y a quelques jours je me suis effectivement aperçu que
si je mettais des contrôles sur deux formulaires Winform ouverts sur la
même table, il y avait un souci du fait que le premier formulaire ouver t
verrouillait la table, et empêchait donc le deuxième de l'ouvrir. C'e st
là que j'ai réécrit le premier formulaire, celui qui affiche les
données, pour parcourir le DataSet à l'ouverture du formulaire et le
fermer ensuite, après avoir affiché les données. Comme ça, quand j'ouvre
le formulaire de modification, je peux accéder aux données. C'est la
situation où j'ai eu à me poser la même question, à défaut d'y répondre.

Ensuite j'ai amélioré les temps de réponse en m'adressant à XML p lutôt
que SQL Server, mais ça ce n'est pas la même question.

Je viens du monde de Delphi, je crois que toi aussi, il n'y avais pas
de souci comme ca.

Ah, non, j'ai pratiqué pas mal de plateformes, mais Delphi pas encore.

Encore une petite question si tu connais la réponse, y a t'il un moy en
de mettre en readonly le bindingSource pour mettre tous les controles
associés en readonly.

Si c'est le cas ça ne saute pas aux yeux en lisant la doc, et
l'IntelliSense ne fait pas non plus apparaître de readonly, donc ...
j'en suis au même point que toi pour ce qui est de faire le verrouillag e
au niveau du BindingSource.
Cela étant, si tu utilises un DataSet dont le TableAdapter comporte une
méthode d'accès aux données (GetData) et pas de méthode d'écrit ure
(Fill), tu es assuré de ne rien modifier dans la table. ça devrait
permettre de faire quelque chose de propre, non ?

Pour la modif d'un label d'une form a une autre, moi j'utilise ca .

Dans form A : un Label1en public

Appel de form B depuis form A
Form FormB = new FormB() ;
FormB.show(this) ;

Dans FormB :
((FormA)Owner).Label1.Text = "toto";

Ah, je crois bien que Owner était justement le mot que je cherchais,
merci. En fait j'ai dû essayer Owner, mais sans avoir repéré qu'il
fallait le préciser à l'ouverture. Label1 doit aussi être public bi en
entendu, moyennant quoi une seule ligne de code suffit. A part show bien
entendu.

Comme quoi, il ne faut pas oublier d'apprendre des débutants ;)

C'est quoi la meilleur solution ??

J'ai l'impression que tu ne dois pas en être loin, quand il s'agit just e
de transmettre une valeur, si on accorde de l'importance à la simplicit é
du code et des notions mises en œuvre.

Ce que suggère Faust est important de par la puissance du mécanisme,
quand il y a un traitement à effectuer en réponse à un événemen t,
notamment sur un autre formulaire. Il faut avoir bien en tête le
mécanisme des délégués (et se l'y remettre de temps en temps), ç a ne
s'improvise pas et on est assuré d'en avoir besoin un jour ou l'autre.

Et bonne vacance a toi.

Merci, je vais tâcher d'y penser aussi. Si j'avais répondu à toutes les
questions je pourrais me permettre :)

/_Gloops_ a couché sur son écran/ :

cc.18 a écrit, le 29/07/2009 10:09 :

Merci de ta reponse,
J'ai essayer de mettre en public mon bindingSource du formulaire A, mais
je ne peux pas le selectionner dans mon dataGridView , proprieté Datasource
qui se trouve sur mon formulaire B ( en conception ).

Je redoutais un peu quelque chose comme ça, ce n'est pas pour rien que je
précisais ne pas avoir essayé.
Si j'ai bien capté ce que dit Faust on peut rendre le contrôle public depuis
la fenêtre des propriétés (propriété Modifiers, ça m'intrigue d'ailleurs que
ce nom soit au pluriel), ça OK, après, pour appeler les données depuis une
DataGrid sur un autre formulaire ...
Bon, si ce que j'ai avancé était une fausse piste, peut-être reste-t-il à
créer une classe d'accès aux données, pour pouvoir l'utiliser depuis
plusieurs formulaires ?
Ou rendre public le DataSet ouvert sur un formulaire pour pouvoir le
parcourir sur un autre -pas la peine que la fenêtre des propriétés permette
de le rendre public si c'est pour ne pas s'en servir. Bon enfin là c'est les
grands principes, parce que je viens quand même de jeter un coup d'½il, au
niveau d'une DataGridView, j'ai accès aux DataSet du projet, mais pas aux
instances créées sur un formulaire. ça ne résout donc pas la question du
verrouillage.

si j'ai bien compris votre problème,c'est faisable, mais pas dans
l'éditeur: ça ne peut se faire qu'à l'exécution
pourquoi ? parce que contrairement à Delphi, visual studio a
l'intelligence de ne pas fournir une variable globale par défaut qu'il
espère qu'on se servira pour stocker l'instance de la fenêtre
du coup, l'editeur n'a pas la prétention de croire que vous allez
effectivement utiliser cette variable, et donc ne peut pas proposer de
lier une propriété d'une classe à la proprité d'une autre classe avant
qu'elle ne soit instanciée
la seule possibilité serait que le bindingsource soit déclaré static
dans la classe de sa fenêtre pour le rendre indépendant de
l'instanciation de la fenêtre associée et pouvoir donc l'utiliser
ailleurs sans être obligé d'instancier la fenêtre

--
Faust
"Une âme en peine peut en cacher une autre"

Faust a écrit, le 30/07/2009 15:48 :

si j'ai bien compris votre problème,c'est faisable, mais pas dans
l'éditeur: ça ne peut se faire qu'à l'exécution
pourquoi ? parce que contrairement à Delphi, visual studio a
l'intelligence de ne pas fournir une variable globale par défaut qu'i l
espère qu'on se servira pour stocker l'instance de la fenêtre
du coup, l'editeur n'a pas la prétention de croire que vous allez
effectivement utiliser cette variable, et donc ne peut pas proposer de
lier une propriété d'une classe à la proprité d'une autre class e avant
qu'elle ne soit instanciée
la seule possibilité serait que le bindingsource soit déclaré sta tic
dans la classe de sa fenêtre pour le rendre indépendant de
l'instanciation de la fenêtre associée et pouvoir donc l'utiliser
ailleurs sans être obligé d'instancier la fenêtre

Je n'ai pas tout compris, à part que tu reprends le fameux "it is not a
bug, it is by design".
Tu dis que c'est mieux ?

Je me doutais que si l'objet était public mais n'apparaissait pas dans
l'interface visuelle, c'est qu'il allait falloir le chercher par code,
et alors là du coup, c'est vrai qu'avec un exemple, on comprend
fichtrement plus vite. Il y en a peut-être en ligne, on en trouve
tellement ...

Ah, l'interface visuelle, il faut avouer que quand ça marche, ça aide
bien, hein. Et puis quand ça ne s'applique pas, eh bieh ... ah ben non
maintenant faut bosser, hein les p'tits gars :)

/_Gloops_ a utilisé son clavier pour écrire/ :

Faust a écrit, le 30/07/2009 15:48 :

si j'ai bien compris votre problème,c'est faisable, mais pas dans
l'éditeur: ça ne peut se faire qu'à l'exécution
pourquoi ? parce que contrairement à Delphi, visual studio a l'intelligence
de ne pas fournir une variable globale par défaut qu'il espère qu'on se
servira pour stocker l'instance de la fenêtre
du coup, l'editeur n'a pas la prétention de croire que vous allez
effectivement utiliser cette variable, et donc ne peut pas proposer de lier
une propriété d'une classe à la proprité d'une autre classe avant qu'elle
ne soit instanciée
la seule possibilité serait que le bindingsource soit déclaré static dans
la classe de sa fenêtre pour le rendre indépendant de l'instanciation de la
fenêtre associée et pouvoir donc l'utiliser ailleurs sans être obligé
d'instancier la fenêtre

Je n'ai pas tout compris, à part que tu reprends le fameux "it is not a bug,
it is by design".

en gros oui
c'est plus que "by design", c'est le concept même de la programmation
orientée objet

pour essayer de prendre un cas concret, tu as deux classes voiture
(form A) et car (form B)
et ce que vous essayez de faire c'est la classe voiture utilise le
moteur du car.... avant qu'il soit construit... forcément ça coince:
tant que le car n'est pas construit, il n'y a pas de moteur à mettre
dans la voiture
(bon en fait je suis pas sûr que ce soit plus clair :) )

Tu dis que c'est mieux ?

c'est pas que c'est mieux: c'est juste conceptuellement impossible
et si dans delphi on peut le faire, c'est que l'éditeur se permet de
prendre des libertés avec les concepts de la POO. Libertés basées sur
des supositions du déroulement du programme: rien ne garanti à
l'éditeur que ce qu'il t'autorise à faire ne plantera pas
lamentablement
là, VS ne t'autorise simplement pas à faire n'importe quoi

--
Faust
"Une âme en peine peut en cacher une autre"

Faust a écrit, le 30/07/2009 16:38 :

là, VS ne t'autorise simplement pas à faire n'importe quoi

Ah, là, je crois que je comprends, même si ce n'est pas forcément t rès
agréable :)

Après, il faut prendre le temps de vraiment monter un projet exemple
pour se rendre compte.

Euh, pour le moment, serait quand même temps que je me mette sur ce que
j'avais prévu de faire cet après-midi :)