Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
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
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:
[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)
Hors ligne
bonjour, il faudrait déclarer gw_fenetre_init dans un type de fenêtre ancêtre qui possède la fonction refresh vide
Hors ligne
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) :
w_menu gw_fenetre_init
Hors ligne
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
Hors ligne
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
Hors ligne
Bonjour,
D'accord, à ce moment la tu peux transformer la méthode w_refresh de w_menu en un événement personnalisé ue_refresh.
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").
Hors ligne
Ok je pense que je vais comme cela
Merci pour tout
Pilou
Hors ligne
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?):
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,... )
Hors ligne
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
Hors ligne
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...
Hors ligne