Discussion :

[Mimouni Mohamed]

Bonjour,

La fonction «ExécuteAncêtre» permet de Surcharger un code.
Alors, quelle est la fonction inverse pour ne pas surcharger le code ?

Cordialement
Mimouni

[Mimouni Mohamed]

Bonjour,

j'ai un modele de champ qui contient un bouton, dans le clic de ce modele j'ai mis une info("Bonjour 1")Aprés j'ai utilisé ce modele dans une fenetre et j'ai mis dans le clic de ce bouton une info("Bonjour 2")A l'exécution, quand je clic sur ce bouton j'ai deux infos

info("Bonjour 1")
info("Bonjour 2")

Ma question : comment faire pour que info("Bonjour 1") ne s'affiche pas

Cordialement
Mimouni

[frenchsting]

Si tu ne veux pas que le code du modèle s'exécute, je ne vois pas l'intérêt d'utiliser un modèle.

[hpascal]

Bonjour

Ma question : comment faire pour que info("Bonjour 1") ne s'affiche pas ?
Mimouni

Il suffit de supprimer ou mettre en commentaire le "ExécuteAncêtre". Ou alors je n'ai pas du tout compris le problème

[Mimouni Mohamed]

Merci frenchsting pour ta réponse

[tatayo]

Bonjour,
Juste pour clarifier, ExecuteAncêtre() ne permet pas de surcharger une procédure/méthode, mais de lancer à partir d'une surcharge de procédure/méthode la version "de base" (l'ancêtre).

Tatayo.

[Mimouni Mohamed]

Bonjour,

Voici une copie d'écran qui explique mon probleme.

J’ai une fenêtre basé sur un modèle de fenêtre.
A l’exécution, j’ai deux infos qui s’affiches.
La première info existe dans la partie « Fin d’initialisation de FEN_Configuration (modèle FENMOD_Form) » partie grisé et non modifiable
La deuxième info existe dans la partie « Fin d’initialisation de FEN_Configuration »
Ma question : comment empêcher ou éliminer l’exécution « Fin d’initialisation de FEN_Configuration (modèle FENMOD_Form) »

Cordialement

[R&B]

Bonjour
Outre de rejoindre les autres réponses, je vous invite modifier le modèle de manière à ce que le code soit soumis aux conditions de l'enfant (on aura tout vu !).
C'est de toute façon un procédé qui pose un problème de conception du modèle (qui est normalement une factorisation d'éléments communs)...

En clair, le modèle doit comporter une procédure d'initialisation qui va affecter une variable créé par le modèle et qui sera évaluée aux moments propices.

Modèle

Code :

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

1
2
3
4
5
6
7
8
9
10
// Declarations globales
fbInitialisation est un booleen = vrai
 
// Initialisation
SI fbInitialisation ALORS
   ...
FIN
 
Procedure modèleInit(bInitialisation est un booleen = vrai)
fbInitialisation = bInitialisation

Et dans l'enfant

Code :

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

1
2
// Declaration
ModeleInit(faux)

[Mimouni Mohamed]

Bonjour,

Merci pour la réponse, mais il n'y a pas un truc comme :
CSharp
Partie Modele

Code C# :

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

1
2
3
4
        public virtual void BeforeLoad()
        {
            ...
        }

Partie Enfant

Code C# :

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

1
2
3
4
5
6
        public override void BeforeLoad()
        {
            ...
            // si je veux lancer la partie modele, je mis la ligne suivante et si je ne met pas, la partie modele ne sera pas exécuter
            base.BeforeLoad(); 
        }

Visual FoxPro
Do Default() pour exécuter la partie modele
NoDefault() pour ne pas exécuter la partie modele

Merci d'avance

[OnePoint]

Bonjour,

@Mimouni,
Je salue ton effort pour présenter le problème dans le message #7.

En lisant de près l'aide en ligne concernant les Modèles de fenêtre et l'héritage
http://doc.pcsoft.fr/?9000087

Il faut distinguer ce qui se passe dans le cas d'un champ (comme le champ bouton dans ton message #2) et dans le cas d'une fenêtre (cf. message #7) car la possibilité de surcharge n'est pas identique.

J'ai l'impression que les "traitements" d'un modèle de fenêtre ne sont pas surchargés par les "traitements" de la fenêtre basée sur le modèle.
En fait les traitements sont appelés successivement, sans possibilité d'empêcher cette cascade d'appel.
Un peu comme en POO, le constructeur d'une classe de base est obligatoirement exécuté avant le constructeur de la classe dérivée.

Si tu veux maîtriser la surcharge du "code d'initialisation" exécuté par le traitement Fin d'initialisation, alors ...

Dans le modèle de fenêtre tu dois:
(1) créer une procédure locale, que tu pourrais nommer FenêtreFinInitialisation() par exemple,
(2) dans cette procédure locale, tu insères le "code d'initialisation",
(3) dans le traitement Fin d'initialisation, tu fais simplement appel à la procédure locale FenêtreFinInitialisation().

Ensuite dans la fenêtre basée sur le modèle tu dois:
(4) surcharger la procédure locale FenêtreFinInitialisation() et insérer le code de ton choix.

Si tu veux exécuter le "code d'initialisation" présent dans le modèle, alors tu utilises l'instruction ExécuteAncêtre.

Voilà ce que je comprends.

Bon dév.

[Mimouni Mohamed]

Bonjour OnePoint

Merci pour votre réponse, c'est une bonne idée.

Mais sauf dans le point (3), il ne faut pas faire appel à la procédure locale FenêtreFinInitialisation().

A par ça tout va bien

Cordialement
Mimouni