Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
JFGerard a écrit :
> Bonjour
> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
> genre xxxxx.controls("LeNomDelObjet").
> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
> (par exemple, a partir de la definition d'un UserControl).
> Exemple :
> soit une classe UserControl appellee ucMonControle,
> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
> CreerObjet(Instance1)
> xid1 = instance1.parent.controls.indexof(Instance1)
> debug.writeln("Etape1 : Id1 = " & xid1)
> CreerObjet(Instance2)
> 'xid2 = instance2.parent.controls.indexof(Instance2)
> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
> avec la procedure
> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
> pObjetACreer = new ucMonControl
> end sub
>
> on se recupere a l'execution quelque chose comme
> Etape 1 xId1 = 0
> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
> pile et que leur "numero" se modifie au cours des empilages/depilages
> d'objets créés dynamiquement.
>
> Est-ce que mon analyse est bonne ?
> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
> l'application ?
> Est-ce un bug ?
> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
> par exemple) ?
>
> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
> interessant !!!!
> JFG
> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
JFGerard a écrit :
> Bonjour
> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
> genre xxxxx.controls("LeNomDelObjet").
> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
> (par exemple, a partir de la definition d'un UserControl).
> Exemple :
> soit une classe UserControl appellee ucMonControle,
> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
> CreerObjet(Instance1)
> xid1 = instance1.parent.controls.indexof(Instance1)
> debug.writeln("Etape1 : Id1 = " & xid1)
> CreerObjet(Instance2)
> 'xid2 = instance2.parent.controls.indexof(Instance2)
> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
> avec la procedure
> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
> pObjetACreer = new ucMonControl
> end sub
>
> on se recupere a l'execution quelque chose comme
> Etape 1 xId1 = 0
> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
> pile et que leur "numero" se modifie au cours des empilages/depilages
> d'objets créés dynamiquement.
>
> Est-ce que mon analyse est bonne ?
> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
> l'application ?
> Est-ce un bug ?
> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
> par exemple) ?
>
> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
> interessant !!!!
> JFG
> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
JFGerard a écrit :
> Bonjour
> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
> genre xxxxx.controls("LeNomDelObjet").
> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
> (par exemple, a partir de la definition d'un UserControl).
> Exemple :
> soit une classe UserControl appellee ucMonControle,
> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
> CreerObjet(Instance1)
> xid1 = instance1.parent.controls.indexof(Instance1)
> debug.writeln("Etape1 : Id1 = " & xid1)
> CreerObjet(Instance2)
> 'xid2 = instance2.parent.controls.indexof(Instance2)
> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
> avec la procedure
> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
> pObjetACreer = new ucMonControl
> end sub
>
> on se recupere a l'execution quelque chose comme
> Etape 1 xId1 = 0
> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
> pile et que leur "numero" se modifie au cours des empilages/depilages
> d'objets créés dynamiquement.
>
> Est-ce que mon analyse est bonne ?
> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
> l'application ?
> Est-ce un bug ?
> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
> par exemple) ?
>
> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
> interessant !!!!
> JFG
> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
Bonjour
ce qui semble vouloir dire que les objets dynamiques ont été créés
dans une pile et que leur "numero" se modifie au cours des
empilages/depilages d'objets créés dynamiquement.
Bonjour
ce qui semble vouloir dire que les objets dynamiques ont été créés
dans une pile et que leur "numero" se modifie au cours des
empilages/depilages d'objets créés dynamiquement.
Bonjour
ce qui semble vouloir dire que les objets dynamiques ont été créés
dans une pile et que leur "numero" se modifie au cours des
empilages/depilages d'objets créés dynamiquement.
dans : news:,
JFGerard écrivait :
> Bonjour
Bonjour,
[...]
> ce qui semble vouloir dire que les objets dynamiques ont été créés
> dans une pile et que leur "numero" se modifie au cours des
> empilages/depilages d'objets créés dynamiquement.
Peut-être, je n'ai pas beacoup pratiqué le compact framework.
Dans ce cas, pourquoi ne pas stocker les instances créées dans ta propre
liste ?
Et sinon (sans avoir pris le temps de vérifier), ne peut-on pas préciser
l'index lors de l'ajout dans le control parent ?
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT
dans : news:4BEBDE3D-452D-4F0B-9C95-C60BD47933C1@microsoft.com,
JFGerard écrivait :
> Bonjour
Bonjour,
[...]
> ce qui semble vouloir dire que les objets dynamiques ont été créés
> dans une pile et que leur "numero" se modifie au cours des
> empilages/depilages d'objets créés dynamiquement.
Peut-être, je n'ai pas beacoup pratiqué le compact framework.
Dans ce cas, pourquoi ne pas stocker les instances créées dans ta propre
liste ?
Et sinon (sans avoir pris le temps de vérifier), ne peut-on pas préciser
l'index lors de l'ajout dans le control parent ?
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT
dans : news:,
JFGerard écrivait :
> Bonjour
Bonjour,
[...]
> ce qui semble vouloir dire que les objets dynamiques ont été créés
> dans une pile et que leur "numero" se modifie au cours des
> empilages/depilages d'objets créés dynamiquement.
Peut-être, je n'ai pas beacoup pratiqué le compact framework.
Dans ce cas, pourquoi ne pas stocker les instances créées dans ta propre
liste ?
Et sinon (sans avoir pris le temps de vérifier), ne peut-on pas préciser
l'index lors de l'ajout dans le control parent ?
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT
Bonjour Fred
Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
n'est pas un invariant caracteristique de l'objet.
Bonjour Fred
Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
n'est pas un invariant caracteristique de l'objet.
Bonjour Fred
Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
n'est pas un invariant caracteristique de l'objet.
Bonjour
Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
question.
Certes, la notion "Index" permet de reperer l'element de base dans la
collection. mais mon souci est que cet index change en cas de creation
dynamique (c'est a dire dans le code).
Dans ton exemple, au depart , effecivement le count est a 0.
Puis et sequentiellement et DANS le code (et pas statiquement dans le
designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
est 0 (la numerotation commence a 0).
MAIS !!!! et c'est la que git le loup,
quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
l'index 1) ...
et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
moyen de faire autrement ?
Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
et semble inapplicable :
Soit x controles identiques créés dynamiquement dans la forme, avec un
evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
procedure gerant l'event dans la form parent.
Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
usercontrol qui a generé l'evenement.
Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
un delai ou une action operateur traitée par une autre procedure. Il n'est
plus possible d'identifier le usercontrol d'origine qui a declenché toutes
les actions en cascade.
Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
passé et qu'il peut "retourner dormir".
ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
la maitrise.
A suivre, SVP au plaisir ...
JFG
"White Water" <"Pure"AntiSpam"Coinciden" a écrit :JFGerard a écrit :Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
Bonjour
Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
question.
Certes, la notion "Index" permet de reperer l'element de base dans la
collection. mais mon souci est que cet index change en cas de creation
dynamique (c'est a dire dans le code).
Dans ton exemple, au depart , effecivement le count est a 0.
Puis et sequentiellement et DANS le code (et pas statiquement dans le
designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
est 0 (la numerotation commence a 0).
MAIS !!!! et c'est la que git le loup,
quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
l'index 1) ...
et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
moyen de faire autrement ?
Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
et semble inapplicable :
Soit x controles identiques créés dynamiquement dans la forme, avec un
evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
procedure gerant l'event dans la form parent.
Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
usercontrol qui a generé l'evenement.
Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
un delai ou une action operateur traitée par une autre procedure. Il n'est
plus possible d'identifier le usercontrol d'origine qui a declenché toutes
les actions en cascade.
Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
passé et qu'il peut "retourner dormir".
ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
la maitrise.
A suivre, SVP au plaisir ...
JFG
"White Water" <"Pure"AntiSpam"Coinciden" a écrit :
JFGerard a écrit :
Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
Bonjour
Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
question.
Certes, la notion "Index" permet de reperer l'element de base dans la
collection. mais mon souci est que cet index change en cas de creation
dynamique (c'est a dire dans le code).
Dans ton exemple, au depart , effecivement le count est a 0.
Puis et sequentiellement et DANS le code (et pas statiquement dans le
designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
est 0 (la numerotation commence a 0).
MAIS !!!! et c'est la que git le loup,
quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
l'index 1) ...
et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
moyen de faire autrement ?
Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
et semble inapplicable :
Soit x controles identiques créés dynamiquement dans la forme, avec un
evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
procedure gerant l'event dans la form parent.
Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
usercontrol qui a generé l'evenement.
Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
un delai ou une action operateur traitée par une autre procedure. Il n'est
plus possible d'identifier le usercontrol d'origine qui a declenché toutes
les actions en cascade.
Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
passé et qu'il peut "retourner dormir".
ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
la maitrise.
A suivre, SVP au plaisir ...
JFG
"White Water" <"Pure"AntiSpam"Coinciden" a écrit :JFGerard a écrit :Bonjour
Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
genre xxxxx.controls("LeNomDelObjet").
Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
n'etaient changeants si on crée dynamiquement les dits-objets dans le code
(par exemple, a partir de la definition d'un UserControl).
Exemple :
soit une classe UserControl appellee ucMonControle,
si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
CreerObjet(Instance1)
xid1 = instance1.parent.controls.indexof(Instance1)
debug.writeln("Etape1 : Id1 = " & xid1)
CreerObjet(Instance2)
'xid2 = instance2.parent.controls.indexof(Instance2)
debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
" & instance2....indexof(Instance2) & "Id1avant = " & xId1)
avec la procedure
private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
pObjetACreer = new ucMonControl
end sub
on se recupere a l'execution quelque chose comme
Etape 1 xId1 = 0
Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
pile et que leur "numero" se modifie au cours des empilages/depilages
d'objets créés dynamiquement.
Est-ce que mon analyse est bonne ?
Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
l'application ?
Est-ce un bug ?
Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
un objet créé dynamiquement par une autre procedure et dont on ne connait pas
le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
par exemple) ?
Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
interessant !!!!
JFG
Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
Bonjour, je suis pas un spécialiste du Compact Framework (ni du
Framework tout court), mais je crois qu'il y à confusion sur la
signification de 'index'.
Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
d'enfant donc ControlParent.controls.count = 0
Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
ControlParent.controls.count=2
Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
1 à 2)
Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
J'espère avoir été claire.
A plus.
JFGerard a écrit :
> Bonjour
> Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
> question.
> Certes, la notion "Index" permet de reperer l'element de base dans la
> collection. mais mon souci est que cet index change en cas de creation
> dynamique (c'est a dire dans le code).
> Dans ton exemple, au depart , effecivement le count est a 0.
> Puis et sequentiellement et DANS le code (et pas statiquement dans le
> designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
> est 0 (la numerotation commence a 0).
> MAIS !!!! et c'est la que git le loup,
> quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
> Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
> l'index 1) ...
> et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
> Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
> et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
> moyen de faire autrement ?
>
> Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
> et semble inapplicable :
> Soit x controles identiques créés dynamiquement dans la forme, avec un
> evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
> procedure gerant l'event dans la form parent.
> Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
> usercontrol qui a generé l'evenement.
> Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
> un delai ou une action operateur traitée par une autre procedure. Il n'est
> plus possible d'identifier le usercontrol d'origine qui a declenché toutes
> les actions en cascade.
> Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
> Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
> donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
> passé et qu'il peut "retourner dormir".
> ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
> la maitrise.
>
> A suivre, SVP au plaisir ...
> JFG
>
> "White Water" <"Pure"AntiSpam"Coinciden" a écrit :
>
>> JFGerard a écrit :
>>> Bonjour
>>> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
>>> genre xxxxx.controls("LeNomDelObjet").
>>> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
>>> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
>>> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
>>> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
>>> (par exemple, a partir de la definition d'un UserControl).
>>> Exemple :
>>> soit une classe UserControl appellee ucMonControle,
>>> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
>>> CreerObjet(Instance1)
>>> xid1 = instance1.parent.controls.indexof(Instance1)
>>> debug.writeln("Etape1 : Id1 = " & xid1)
>>> CreerObjet(Instance2)
>>> 'xid2 = instance2.parent.controls.indexof(Instance2)
>>> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
>>> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
>>> avec la procedure
>>> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
>>> pObjetACreer = new ucMonControl
>>> end sub
>>>
>>> on se recupere a l'execution quelque chose comme
>>> Etape 1 xId1 = 0
>>> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
>>> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
>>> pile et que leur "numero" se modifie au cours des empilages/depilages
>>> d'objets créés dynamiquement.
>>>
>>> Est-ce que mon analyse est bonne ?
>>> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
>>> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
>>> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
>>> l'application ?
>>> Est-ce un bug ?
>>> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
>>> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
>>> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
>>> par exemple) ?
>>>
>>> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
>>> interessant !!!!
>>> JFG
>>> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>>>
>> Bonjour, je suis pas un spécialiste du Compact Framework (ni du
>> Framework tout court), mais je crois qu'il y à confusion sur la
>> signification de 'index'.
>>
>> Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
>>
>> Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
>> d'enfant donc ControlParent.controls.count = 0
>>
>> Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
>> ControlParent.controls.count=2
>>
>> Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
>> 1 à 2)
>>
>> Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
>>
>> J'espère avoir été claire.
>>
>> A plus.
>>
============================================================================ >
Bonsoir,
Après vérification il semble que l'ajout de contrôles sur une Form ne
change pas l'ordre des index :
Dim ctrl as control
ctrl = new label
Me.add(ctrl)
ctrl = new comboBox
Me.add(ctrl)
Label a l'index 0 et le combo l'index 1. Peut être est ce une
incohérence du Compact Framework.
Et comme dit Fred pourquoi ne pas référencer les contrôles au fur et à
mesure de leur création dans une collection ?
dim CtrlCol as new collection
dim Ctrl as control
ctrl = new label
ctrlcol.add(ctrl,"Contrôle1")
ctrl = new label
ctrlcol.Add(ctrl,"Contrôle2")
Je ne sais pas si c'est bien cela que vous recherchez, je dois bien
avouer que je n'est pas bien compris ce que vous vouliez faire au juste.
A plus.
JFGerard a écrit :
> Bonjour
> Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
> question.
> Certes, la notion "Index" permet de reperer l'element de base dans la
> collection. mais mon souci est que cet index change en cas de creation
> dynamique (c'est a dire dans le code).
> Dans ton exemple, au depart , effecivement le count est a 0.
> Puis et sequentiellement et DANS le code (et pas statiquement dans le
> designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
> est 0 (la numerotation commence a 0).
> MAIS !!!! et c'est la que git le loup,
> quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
> Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
> l'index 1) ...
> et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
> Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
> et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
> moyen de faire autrement ?
>
> Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
> et semble inapplicable :
> Soit x controles identiques créés dynamiquement dans la forme, avec un
> evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
> procedure gerant l'event dans la form parent.
> Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
> usercontrol qui a generé l'evenement.
> Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
> un delai ou une action operateur traitée par une autre procedure. Il n'est
> plus possible d'identifier le usercontrol d'origine qui a declenché toutes
> les actions en cascade.
> Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
> Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
> donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
> passé et qu'il peut "retourner dormir".
> ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
> la maitrise.
>
> A suivre, SVP au plaisir ...
> JFG
>
> "White Water" <"Pure"AntiSpam"Coinciden" a écrit :
>
>> JFGerard a écrit :
>>> Bonjour
>>> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
>>> genre xxxxx.controls("LeNomDelObjet").
>>> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
>>> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
>>> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
>>> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
>>> (par exemple, a partir de la definition d'un UserControl).
>>> Exemple :
>>> soit une classe UserControl appellee ucMonControle,
>>> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
>>> CreerObjet(Instance1)
>>> xid1 = instance1.parent.controls.indexof(Instance1)
>>> debug.writeln("Etape1 : Id1 = " & xid1)
>>> CreerObjet(Instance2)
>>> 'xid2 = instance2.parent.controls.indexof(Instance2)
>>> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
>>> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
>>> avec la procedure
>>> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
>>> pObjetACreer = new ucMonControl
>>> end sub
>>>
>>> on se recupere a l'execution quelque chose comme
>>> Etape 1 xId1 = 0
>>> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
>>> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
>>> pile et que leur "numero" se modifie au cours des empilages/depilages
>>> d'objets créés dynamiquement.
>>>
>>> Est-ce que mon analyse est bonne ?
>>> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
>>> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
>>> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
>>> l'application ?
>>> Est-ce un bug ?
>>> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
>>> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
>>> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
>>> par exemple) ?
>>>
>>> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
>>> interessant !!!!
>>> JFG
>>> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>>>
>> Bonjour, je suis pas un spécialiste du Compact Framework (ni du
>> Framework tout court), mais je crois qu'il y à confusion sur la
>> signification de 'index'.
>>
>> Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
>>
>> Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
>> d'enfant donc ControlParent.controls.count = 0
>>
>> Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
>> ControlParent.controls.count=2
>>
>> Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
>> 1 à 2)
>>
>> Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
>>
>> J'espère avoir été claire.
>>
>> A plus.
>>
============================================================================ >
Bonsoir,
Après vérification il semble que l'ajout de contrôles sur une Form ne
change pas l'ordre des index :
Dim ctrl as control
ctrl = new label
Me.add(ctrl)
ctrl = new comboBox
Me.add(ctrl)
Label a l'index 0 et le combo l'index 1. Peut être est ce une
incohérence du Compact Framework.
Et comme dit Fred pourquoi ne pas référencer les contrôles au fur et à
mesure de leur création dans une collection ?
dim CtrlCol as new collection
dim Ctrl as control
ctrl = new label
ctrlcol.add(ctrl,"Contrôle1")
ctrl = new label
ctrlcol.Add(ctrl,"Contrôle2")
Je ne sais pas si c'est bien cela que vous recherchez, je dois bien
avouer que je n'est pas bien compris ce que vous vouliez faire au juste.
A plus.
JFGerard a écrit :
> Bonjour
> Merci de cette reponse, claire dans son contenu mais qui ne repond pas a ma
> question.
> Certes, la notion "Index" permet de reperer l'element de base dans la
> collection. mais mon souci est que cet index change en cas de creation
> dynamique (c'est a dire dans le code).
> Dans ton exemple, au depart , effecivement le count est a 0.
> Puis et sequentiellement et DANS le code (et pas statiquement dans le
> designer), on cree Enfant1, le compte passe a 1 et l'index associé a Enfant1
> est 0 (la numerotation commence a 0).
> MAIS !!!! et c'est la que git le loup,
> quand on crée, DANS le code, Enfant2, le compte passe a 2 (pas de pb) mais
> Enfant2 'pousse' Enfant1 et prend sa place a l'index 0 (et Enfant1 prend
> l'index 1) ...
> et si on crée Enfant3, pouf pouf , il pousse 1 et 2, prend l'index 0 et
> Enfant2 prend l'index 1 et Enfant1 prend l'index 2 ... and so on ...
> et ma question reste entiere : est-ce normal ou est un bug ou y-at-il un
> moyen de faire autrement ?
>
> Quant a la solution Handle, je veux bien , mais elle me pose d'autres soucis
> et semble inapplicable :
> Soit x controles identiques créés dynamiquement dans la forme, avec un
> evenement (action sur un bouton du usercontrol) par exemple, et UNE seule
> procedure gerant l'event dans la form parent.
> Tant qu'on est dans cette procedure, tout va bien, on sait quel est le
> usercontrol qui a generé l'evenement.
> Mais a supposer qu'on declenche a ce moment un traitement qui se termine sur
> un delai ou une action operateur traitée par une autre procedure. Il n'est
> plus possible d'identifier le usercontrol d'origine qui a declenché toutes
> les actions en cascade.
> Et meme si on stocke le nom de ce usercontrol (une string), comme en Compact
> Fwk, la fonction Controls n'accepte pas ce type d'argument on est blousé, et
> donc on ne sait jamais comment indiquer a ce usercontrol que tout c'est bien
> passé et qu'il peut "retourner dormir".
> ou alors il a des possibilites dans la gestion des handles dont je n'ai pas
> la maitrise.
>
> A suivre, SVP au plaisir ...
> JFG
>
> "White Water" <"Pure"AntiSpam"Coinciden" a écrit :
>
>> JFGerard a écrit :
>>> Bonjour
>>> Dans le fmk standard, tout objet (ou presque) est accessible par un truc du
>>> genre xxxxx.controls("LeNomDelObjet").
>>> Malheureusement dans le Compact Framework, la propriété .Controls n'accepte
>>> que l'ID de l'objet (un integer) et pas le nom. Ce ne serait pas trop grave
>>> si les numeros des objets (l'Id recuperable par la fonction IndexOf(LObjet) )
>>> n'etaient changeants si on crée dynamiquement les dits-objets dans le code
>>> (par exemple, a partir de la definition d'un UserControl).
>>> Exemple :
>>> soit une classe UserControl appellee ucMonControle,
>>> si on ecrit (j'ai condensé l'integralite du code mais c'est l idee)
>>> CreerObjet(Instance1)
>>> xid1 = instance1.parent.controls.indexof(Instance1)
>>> debug.writeln("Etape1 : Id1 = " & xid1)
>>> CreerObjet(Instance2)
>>> 'xid2 = instance2.parent.controls.indexof(Instance2)
>>> debug.writeln("Etape2 : Id1 = " & instance1....indexof(Instance1) & " Id2 =
>>> " & instance2....indexof(Instance2) & "Id1avant = " & xId1)
>>> avec la procedure
>>> private sub CreerObjet(byRef pObjetacreer as ucMoncontrol)
>>> pObjetACreer = new ucMonControl
>>> end sub
>>>
>>> on se recupere a l'execution quelque chose comme
>>> Etape 1 xId1 = 0
>>> Etape 2 xId1 = 1 xId2 = 0 xId1avant = 0
>>> ce qui semble vouloir dire que les objets dynamiques ont été créés dans une
>>> pile et que leur "numero" se modifie au cours des empilages/depilages
>>> d'objets créés dynamiquement.
>>>
>>> Est-ce que mon analyse est bonne ?
>>> Est-ce normal (auquel cas l'interet me semble limité parce que cela veut
>>> dire qu'on ne peut reutiliser cet Id qu'en ayant la certitude qu'aucun autre
>>> objet n'a été créé dynamiquement par ailleurs, et par la suite, dans
>>> l'application ?
>>> Est-ce un bug ?
>>> Quelqu'un a-t-il une meilleure solution pour referencer dans une procedure
>>> un objet créé dynamiquement par une autre procedure et dont on ne connait pas
>>> le nom à l'avance (pour la gestion d'evenements declenchés par le UserControl
>>> par exemple) ?
>>>
>>> Cordialement, et désolé si le texte est un peu long, mais le sujet me semble
>>> interessant !!!!
>>> JFG
>>> Ok pour poursuivre offline si necessaire (et publication du resultat !!!)
>>>
>> Bonjour, je suis pas un spécialiste du Compact Framework (ni du
>> Framework tout court), mais je crois qu'il y à confusion sur la
>> signification de 'index'.
>>
>> Index c'est le rang du contrôle dans la collection de 'Controls' du parent.
>>
>> Soit un contrôle nommé 'ControlParent', lorsqu'il est créer il n'a pas
>> d'enfant donc ControlParent.controls.count = 0
>>
>> Si tu lui ajoute ControlEnfant1 et ControlEnfant2, alors
>> ControlParent.controls.count=2
>>
>> Et ControlParent.controls.item(Index) = ControlEnfant (Index variant de
>> 1 à 2)
>>
>> Si tu veux un chiffre référençant ton contrôle prend ControlEnfant.handle.
>>
>> J'espère avoir été claire.
>>
>> A plus.
>>
============================================================================ >
Bonsoir,
Après vérification il semble que l'ajout de contrôles sur une Form ne
change pas l'ordre des index :
Dim ctrl as control
ctrl = new label
Me.add(ctrl)
ctrl = new comboBox
Me.add(ctrl)
Label a l'index 0 et le combo l'index 1. Peut être est ce une
incohérence du Compact Framework.
Et comme dit Fred pourquoi ne pas référencer les contrôles au fur et à
mesure de leur création dans une collection ?
dim CtrlCol as new collection
dim Ctrl as control
ctrl = new label
ctrlcol.add(ctrl,"Contrôle1")
ctrl = new label
ctrlcol.Add(ctrl,"Contrôle2")
Je ne sais pas si c'est bien cela que vous recherchez, je dois bien
avouer que je n'est pas bien compris ce que vous vouliez faire au juste.
A plus.
dans : news:,
JFGerard écrivait :
> Bonjour Fred
Bonsoir,
> Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
> n'est pas un invariant caracteristique de l'objet.
Oui, c'est pour cela que je te proposais de stocker les contrôles
eux-mêmes (ou tout du moins leurs références) dans une liste que tu
gères toi-même. Mais je ne sais pas si cela colle avec ce que tu
envisages de faire ensuite.
MesControles.Add(instance1)
MesControles.Add(instance2)
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT
dans : news:7B58FC36-BD50-4A21-872D-064084E8B689@microsoft.com,
JFGerard écrivait :
> Bonjour Fred
Bonsoir,
> Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
> n'est pas un invariant caracteristique de l'objet.
Oui, c'est pour cela que je te proposais de stocker les contrôles
eux-mêmes (ou tout du moins leurs références) dans une liste que tu
gères toi-même. Mais je ne sais pas si cela colle avec ce que tu
envisages de faire ensuite.
MesControles.Add(instance1)
MesControles.Add(instance2)
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT
dans : news:,
JFGerard écrivait :
> Bonjour Fred
Bonsoir,
> Merci de ta reponse, mais, non, ca ne marche pas parce que l'index
> n'est pas un invariant caracteristique de l'objet.
Oui, c'est pour cela que je te proposais de stocker les contrôles
eux-mêmes (ou tout du moins leurs références) dans une liste que tu
gères toi-même. Mais je ne sais pas si cela colle avec ce que tu
envisages de faire ensuite.
MesControles.Add(instance1)
MesControles.Add(instance2)
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
http://www.mailfusible.com/?3kA6ftaCvT