Tron a écrit:

Alors, combien de pépites pour ces 2 astuces ?

Tron

1 pépite par astuce, car les pépites ne se demandent pas
98 pour le choix de ton pseudo.
Soit 00 pépites

Ouuuuah !

C'est vrai, mais ...

il est parfois interressant d'avoir plusieurs constructeurs avec des paramètres différents

et avec PB,

il est impossible (?) de d'avoir deux event avec le même nom et des arguments différents...

Pour gérér les erreurs j'utilise des try/catch...

Event ou fonction, pour la moi la question reste ouverte...

A+

Un truc comme ça ?

global type s_chrnico from structure
  long    l_array[]
  string    s_array[]
  double    d_array[]
  date    dt_array[]
  powerobject  po_array[]
end type

Pourquoi pas, mais ...

dans ce cas tu rajoutes une nouvelle classe ou une structure et ... donc une nouvelle dépendance...

dans l'évent (si tu utilise une structure avec des tableau), tu es obligé d'écrire qq chose comme :

...
ls_xxx = ast_param.s_array[ xxx ]
ll_xxx = ast_param.l_array[ yyy ]
...

c'est moins lisible

Dernière modification par Tron (20-09-2007 09:56:28)

Ce qui me gêne le plus c'est d'ajouter un nouvel objet ....

JCZ a écrit:

Pouvoir ouvrir dynamiquement des users objects ?

Pas dynamiquement, au sens ne pas connaitre le nom de la classe à instancier.
Mais de pouvoir ajouter des paramêtres au constructor du NVO.

Par exemple, au lieu d'écrire :

logger = create nvo_logger
logger.of_init ("C:\temp\foobar.log", Append!)

On écrirait :

logger = f_create ("nvo_logger", "C:\temp\foobar.log", Append!)

Jusqu'au jour où tu vas écrire :

logger = create nvo_logger
logger.log ("Hello world")

Chrnico, quelle est la raison qui t'as poussé à écrire cet objet au lieu de faire de la moto ?

eRaSorZ a écrit:

J'ai pas été clair ?

Logger est un objet qui sert à écrire dans un fichier texte.
Or, il lui faut savoir dans quel fichier écrire sinon ça marche pas

Non mon objet ne peut pas être autoinstanciate car sont état doit être persistant entre le moment où on push les param et le moment ou on les lit. Je pense que vous n'avez pas bien compris l'intérêt de la chose.
Cet objet peut être utilisé partout où vous avez au moins un paramètre à passer à une fonction ou un event.

n_param ln_param
ln_param = create n_param

ln_param.uf_set_param("nom","toto")
ln_param.uf_set_param("age",99)

openwithparm(w_truc, ln_param)

Dans la fenêtre appelée...

// déclaré en instance de ma fenêtre n_param in_param
in_param = Message.PowerObjectParm

if integer(in_param.uf_get_param("age")) > 50 then
   Messagebox("Erreur", "Monsieur " + string(in_param.uf_get_param("nom")) + " est trop vieux !")
end if

Imaginons que nous devions passer un autre paramètre à cette fenêtre. Il suffit de rajouter un ln_param.uf_set_param("param",valeur) avant l'appel de la fonction sans modifier son appel . Imaginez un CloseWithReturn(in_param). Cela permet de contourner le problème de non polymorphisme des events (ou d'écrire 20 prototypes d'une même fonction). Pour ceux qui ne voit toujours pas d'intérêt. Je suis désolé...

eRaSorZ a écrit:

Chrnico a écrit:

Non mon objet ne peut pas être autoinstanciate car sont état doit être persistant entre le moment où on push les param et le moment ou on les lit. Je pense que vous n'avez pas bien compris l'intérêt de la chose.
Cet objet peut être utilisé partout où vous avez au moins un paramètre à passer à une fonction ou un event.

Imaginons que nous devions passer un autre paramètre à cette fenêtre. Il suffit de rajouter un ln_param.uf_set_param("param",valeur) avant l'appel de la fonction sans modifier son appel . Imaginez un CloseWithReturn(in_param). Cela permet de contourner le problème de non polymorphisme des events (ou d'écrire 20 prototypes d'une même fonction). Pour ceux qui ne voit toujours pas d'intérêt. Je suis désolé...

L'intéret d'un tel objet est clair, mais on a un peu dévié de la discussion initiale. Cet objet aurait mérité un post spécifique du genre déclarer et utiliser un objet paramètre

Non, je répondais au problème d'origine :
1 la fonction constructeur doit obligatoirement exister avec le bon nombre de paramètres => non si c'est un event
2 il faut prototyper une fonction constructeur avec 1 param any, puis une avec 2 param any, puis 3, 4, etc... => non on utilise le fameux objet n_param qui évite un trop grand nombre de prototypage.

L'intérêt d'avoir les arguments au constructeur au lieu d'un of_init après.
C'est que rien ne garantie que lors du of_init l'objet existe toujours
et conceptuellement, se dire que l'objet est contruit avec ses propriétés au lieu de modifier les propriétés après peu avoir du sens. Là je rejoins TRON

Chrnico a écrit:

2 il faut code une fonction constructeur avec 1 param any, puis une avec 2 param any, puis 3, 4, etc... => non on utilise le fameux objet n_param qui évite un trop grand nombre de prototypage.

il n'y a pas que des avantages : en gros tu peux passer tout et n'importe quoi à ta fonction
le prototypage permet à la compilation de s'assurer que tous les cas ont été pris en compte

Chrnico a écrit:

L'intérêt d'avoir les arguments au constructeur au lieu d'un of_init après. C'est que rien ne garantie que lors du of_init l'objet existe toujours

et si tu fais ton of_init juste après le create avec un IsValid ?


  Sur l'utilisation des paramètres de type Any : tu seras obligé de "caster" ensuite (et ça n'est supporté sur toutes les plateformes)