Discussion :

[sgmsg]

Bonjour à tous

J'ai une suite de traitement à faire ... Dont le programme me semble mal adapté voire inefficace sinon archaïque...

Programme Principal:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
    if MonTruc.AAA(Nouvelledonnee) then 
         if MonTruc.BBB(parametres_BBB) then 
               if MonTruc.CCC(parametres_CCC) then 
                      AutreComposant.agit(...)

Donc il ne serait pas mieux de transformer ou d'ajouter des événements pour modifier ou non les paramètres_BBB ou paramètres_CCC et laisser le composant gérer l'appel de MonTruc.BBB et MonTruc.CCC?

Si oui comment doivent être associé les évènements dans les routines ? Ou comment indiquer dans les routines qu'elle doivent attendre et tenir compte des les paramètres si les événements sont référencé dans la fiche principal?

Merci d'avance

[e-ric]

Salut

J'avoue ne pas trop comprendre ton problème. En quoi le code cité est-il archaïque ?
Que veux-tu au juste transformer en événement ?
Sous réserve de la compréhension de ton problème, transformer des méthodes en événements ne simplifiera sans doute pas ton programme.
L'ajout d'un événement dans le composant suppose un besoin récurrent et aura un impact sur tout ton application (voire tes application selon les cas).

Cdlt

[sgmsg]

Merci pour ta réponse.

Effectivement ce n'est pas limpide.

La réalité c'est que
Si MonTruc.AAA est vrai, nécessairement MonTruc.BBB doit être lancé.
Si MonTruc.BBB est vrai, nécessairement MonTruc.CCC doit être lancé.
Si MonTruc.CCC est vrai, nécessairement une procédure externe doit être lancé.

Et cette gestion est faite dans le programme principal et non dans le composant. Donc à chaque utilisation du composant dans un nouveau programme la structure imbriquée doit être implanté dans le programme principal.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    if MonTruc.AAA(Nouvelledonnee) then 
         if MonTruc.BBB(parametres_BBB) then 
               if MonTruc.CCC(parametres_CCC) then 
                      AutreComposant.agit(...)

On est très loin du principe de la boîte noire...

Peut-être que la solution est simplement de faire une routine MonTruc.DDD qui recrée simplement cette structure imbriqué.

C'est vrai que aussi qu'en utilisant des événements, on perd l'exécution synchrone. Il ne faut surtout pas qu'une série d'événements déclenchés soient empilés sans être exécutés.

À l'origine l'idée derrière cette structure imbriqué était de changer les paramètres lors des appels de chaque routine.

[sgmsg]

Merci de votre aide

Je vais intégrer toutes ces routines dans une seule et changerai les paramètres de chaque routine dans des nouvelles propriétés du composant principal.

Si vous avez d'autres commentaires je suis encore preneur

A+

Merci

[tourlourou]

Ce qui serait choquant serait plus de ne pas prévoir dans le code externe quoi faire si les conditions ne sont pas remplies...

Ça reste au programme appelant de gérer l'ordonnancement des tâches et la communication avec l'utilisateur.

Si on peut automatiser le processus sans perdre d'occasion d'interaction pour l'appelant, pourquoi ne pas l'encapsuler, effectivement. Pour ça, il faut savoir quoi faire si MonTruc.AAA est faux, ou MonTruc.BBB, ou MonTruc.CCC.

[sgmsg]

Merci pour ta réponse

Dès qu'une routine est fausse tout s'arrête. On doit attendre que (UneNouvelleDonnee) occasionne la réaction en chaine soit trois vrais consécutifs.

[tourlourou]

Dans ce cas, et pour autant que tous les paramètres soient connus lors de l'appel à AAA ([EDIT] ou passés par référence), autant ajouter une méthode à l'objet (dans son propre code) ou dériver l'objet dans le code de l'appelant pour recréer une boîte noire.