PowerBuilder à Donf ! / [RESOLU] Window en variable globale

Pilou007 · 10-12-2008 09:41:46

Salut
Après une petite recherche, j'ai trouvé quelques truc, mais ils ne répondent pas complètement à mon problème, alors je post:p...

Voilou, j'ai une variable globale

Code: pb

window  gw_fenetre_init
//dans l'open de l'appli
gw_fenetre_init = w_menu

open(gw_fenetre_init)

//puis quelque part dans mon code
gw_fenetre_init.refresh() //--> et là ça plante

la fonction refresh est une focntion de la fenetre w_menu, dans l'absolu, je devrait faire:

Code: pb

[b]w_menu  gw_fenetre_init[/b]

open(gw_fenetre_init)

//puis quelque part dans mon code
gw_fenetre_init.refresh()
...

Et là plus de problème, mais je ne peux pas pour diverses raison...

ma question est pourquoi lorsque je fait
window gw_fenetre_init, puis gw_fenetre_init = w_menu, la variable globale ne prend pas vraiment le type w_menu???
Suis-je clair???
Merci pour vos lumières:d
Pilou
Bye

Dernière modification par Pilou007 (10-12-2008 11:08:37)

erasorz · 10-12-2008 09:47:11

bonjour, il faudrait déclarer gw_fenetre_init dans un type de fenêtre ancêtre qui possède la fonction refresh vide

buck · 10-12-2008 10:08:01

Bonjour,

Tous simple, ta déclaration de variable est erronée (le type window n'a pas de méthode refresh, c'est w_menu) :

Code: PB

w_menu gw_fenetre_init

erasorz · 10-12-2008 10:14:46

sauf si gw_fenetre_init peut être d'un autre type que w_menu...
c'est pour ça que j'ai suggéré de faire une fenêtre ancêtre

Pilou007 · 10-12-2008 10:33:54

Effectivement, gw_fenetre_init peut être d'un autre type, c'est la raison pour laquelle elle est déclarée en window....
je peux par contre utiliser les Dynamic event et Dynamic function, par contre je ne sais pas comment remplacer:
w_menu.cb_nouveau. triggerevent(clicked!) par un truc dynamic...
Merci

buck · 10-12-2008 10:48:29

Bonjour,

D'accord, à ce moment la tu peux transformer la méthode w_refresh de w_menu en un événement personnalisé ue_refresh.

Code: PB

gw_fenetre_init.TriggerEvent("ue_refresh")

Si l'événement n'existe pas pour la fenêtre, il ne se passera rien. Tu as également la possibilité de procéder comme erasorz avec un ancêtre commun à toutes tes fenêtres avec le prototype de ta fonction.

De même avec w_menu.cb_nouveau. triggerevent(clicked!), tu peux créer un événement personnalisé ue_new dans w_menu avec :

cb_nouveau. triggerevent(clicked!) et tu l'invoques par gw_fenetre_init.TriggerEvent("ue_new").

Pilou007 · 10-12-2008 11:08:11

Ok je pense que je vais comme cela
Merci pour tout
Pilou

Cortex · 10-12-2008 11:54:48

Oui, mais dès lors, tu perd la sémantique que tu voulais donner à ta fonction en la transformant en event pour un motif technique... En plus, point de vue héritage, méthodes et event ont un comportement différent.

Sinon, il reste possible de faire une invocation dynamique (pourquoi tu ne le fais pas?):

Code: pb

gw_fenetre_init.dynamic refresh()

Evidemment, en faisant ça, la résolution de l'invocation n'est controlée qu'à l'exécution, pas avant (PB l'ignore). Donc si refresh() n'existe pas, c'est la cata...
Donc... pas oublier avant de vérifier si la méthode existe... (pistes: classdefinition, findmatchingfunction,... )

Pilou007 · 10-12-2008 12:58:29

Effectivement, l'appel dynamic est l'idéal, par contre comme tu dis, tu n'es pas à l'abri d'un problème au moment de l'exécution, en plus vu que le code n'est compilé qu'à ce moment là, tu ralenti aussi ton appli.
En plus, comme je le disais tu ne peux apparemment pas faire d'appel dynamic type gw_fenetre_init. Dynamic cb_refresh.triggerevent(constructor!), par exemple....
Donc en appelant un event de ma fenetre (ue_cb_refresh) dans lequel je mets l'appel (cb_refresh.triggerevent(constructor!)) je résouds mon problème, pour les fonction, je peux faire les deux, mais je préfère cette solution pour éviter les problème dits au début...
Merci pour tout
Pilou007

Cortex · 10-12-2008 13:13:52

Ok, mais pour info, parce que je vois que ce n'est pas clair:
- un appel dynamique ne compile pas à l'execution. C'est du late binding, qui est interpreté par la PBVM, pas exécuté.
- l'appel dynamique en PB consomme plus de temps qu'un appel statique, lors du 1er appel.
- les cas de late binding dans PB qui correspondent à cette baisse de perfs sont: l'appel dynamique de méthode, l'appel dynamique d'event, le triggerevent(string ou enuméré), l'accès aux membres d'un oleObject et l'accès aux membres de datawindow.object.
- Jamais plus d'une clause dynamic par ligne, et uniquement sur le dernier appel! (pas de object.dynamic getparent().getValue() par exemple...)
- On ne peut pas faire de la référence dynamique (ici ton dynamic cb_refresh). Par contre, une fenêtre possède une propriété object[] (ou objetcs[] ??) qui contient tous les controles visuels dont elle est le parent. Et les éléments de cet array ont un classname (ici "cb_refresh") et peuvent servir de base à n'importe quel appel dynamic.

Voili, voilou...

PB à toute heure et à tout moment. (à parcourir avec modération)

Annonce

#1 10-12-2008 09:41:46

[RESOLU] Window en variable globale

Code: pb

Code: pb

#2 10-12-2008 09:47:11

Re: [RESOLU] Window en variable globale

#3 10-12-2008 10:08:01

Re: [RESOLU] Window en variable globale

Code: PB

#4 10-12-2008 10:14:46

Re: [RESOLU] Window en variable globale

#5 10-12-2008 10:33:54

Re: [RESOLU] Window en variable globale

#6 10-12-2008 10:48:29

Re: [RESOLU] Window en variable globale

Code: PB

#7 10-12-2008 11:08:11

Re: [RESOLU] Window en variable globale

#8 10-12-2008 11:54:48

Re: [RESOLU] Window en variable globale

Code: pb

#9 10-12-2008 12:58:29

Re: [RESOLU] Window en variable globale

#10 10-12-2008 13:13:52

Re: [RESOLU] Window en variable globale

Pied de page des forums