Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

pour un specialiste du Compact Framework : creation dynamique d'ob

8 réponses
Avatar
JFGerard
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 !!!)

8 réponses

Avatar
White Water
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.
Avatar
JFGerard
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.



Avatar
Fred
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
Avatar
JFGerard
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.
Comme je l'ai presenté dans ma question (mais peut-etre est-ce mal ecrit,
desolé),
si je crée Enfant1 (premier objet fils), il recoit l'index 0, MAIS
si je crée, après, Enfant2 (second objet fils), il prend l'index 0, pousse
Enfant1 en index valant 1, et
si je crée après Enfant3 (troisieme fils), il prend a son tour l'index 0,
pousse Enfant2 en Index valant 1 qui pousse Enfant1 en Index valant 2 !!!!!

La galere ! parce que si au moment de la creation, tu stockes l'index et
que, apres, dans le cours de l'application, il y a creation d'un nouvel
objet, quelqu'il soit, ca devient le drame :
dynamiquement tous les controles enfants se decalent dans la liste des
controles, mais chaque valeur eventuellement transmise au controle lui-meme
ou stockee dans une table est restee comme a l'origine et evidemment ca y
fait beaucoup moins bien !!!

merci de ton aide
JFG

"Fred" a écrit :

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




Avatar
Fred
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
Avatar
White Water
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.
Avatar
JFGerard
Bonjour, a tous les deux (Fred et WW) :

Je n'avais effectivement pas vu cette approche de stocker dans une
collection les controles au fur et a mesure de leur creation. Ca pourrait
m'aider a recuperer le controle qui m'interesse sans passer par les fonctions
comme Controls ou Indexof.
Je vais tenter d'experimenter cela mais, comme je suis occupé par ailleurs
pendant 48 heures, je ne vous donnerai de nouvelles que la semaine prochaine.
Depuis hier, j'ai essayé une autre approche parce que je trouvais que les
temps d'execution et de rafraichissement sur le Pda etaient a la limite de
l'insupportable. Je n'ai pas pas reussi a savoir si cela tenait a
l'environnement de debug avec execution du code sur le Pda ou a la structure
meme de la solution et du code implementé.
J'ai quand meme l'impression que le code .Net sur un pda ne permet pas
d'être aussi "objet" qu'on pourrait le penser parce que les temps d'execution
passés a faire des New et des Dispose limitent vraiment le recours a ce type
de solutions.
Merci de ce coup de main et de ces idees.
JFG


"White Water" <"Pure"AntiSpam"Coinciden" a écrit :

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.



Avatar
JFGerard
Bonjour, a tous les deux (Fred et WW) :

Je n'avais effectivement pas vu cette approche de stocker dans une
collection les controles au fur et a mesure de leur creation. Ca pourrait
m'aider a recuperer le controle qui m'interesse sans passer par les fonctions
comme Controls ou Indexof.
Je vais tenter d'experimenter cela mais, comme je suis occupé par ailleurs
pendant 48 heures, je ne vous donnerai de nouvelles que la semaine prochaine.
Depuis hier, j'ai essayé une autre approche parce que je trouvais que les
temps d'execution et de rafraichissement sur le Pda etaient a la limite de
l'insupportable. Je n'ai pas pas reussi a savoir si cela tenait a
l'environnement de debug avec execution du code sur le Pda ou a la structure
meme de la solution et du code implementé.
J'ai quand meme l'impression que le code .Net sur un pda ne permet pas
d'être aussi "objet" qu'on pourrait le penser parce que les temps d'execution
passés a faire des New et des Dispose limitent vraiment le recours a ce type
de solutions.
Merci de ce coup de main et de ces idees.
JFG




"Fred" a écrit :

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