Discussion :

[Invité1]

Bonjour,

Je voudrais créer une librairie de classe qui contiendrait un objet que je pourrais implémenter à ma fenêtre. Cet objet devrait avoir à la fois des membres à implémenter et des membres déja définit dans l'objet.

Pour certaines raison cet objet doit absolument être implémenté à la fenêtre de l'application. J'ai donc cherché du côté des interfaces mais le problème evident c'est que ça ne me permet pas de definir des méthodes. J'ai donc tenter de créer une classe avec des membres abstrait et des membres definit mais cette fois mon problème vient du fait qu'il est impossible de l'implementer à la fenêtre le type de base étant différent.

J'aurais donc besoin de vos conseils afin de me guider un peu pour que je puisse orienter mes recherches.

Merci.
Lionel.

NB : j'utilise WPF mais cela ne doit pas avoir d'importance dans le cas présent.

[Guulh]

Il n'y a pas d'héritage multiple en C#. par contre, si tu veux que plusieurs classes partagent du code, il te suffit de mettre ce code dans une classe TaForm qui hérite de Form, et faire hériter tes fenêtres de cette classe TaForm.

Je ne sais pas comment ça se passe en WPF (vivement que je m'y mette ) mais en WinForms, me semble que le designer supporte très mal les forms héritant de forms abstraites.

[SaumonAgile]

Le designer WinForms s'en sors pas mal avec les forms héritées. Tu peux créer une classe de base avec tous tes comportements. Si toutes tes classes qui vont en hériter sont des forms => Dans ce cas, ta classe de base héritera de Form.
Sinon ce sera plus complexe, tu devras peut-être passer par un pattern du genre "décorateur" (à confirmer).

[SirJulio]

Je ne sais pas comment ça se passe en WPF (vivement que je m'y mette ) mais en WinForms, me semble que le designer supporte très mal les forms héritant de forms abstraites.

Salut,

pour Winforms, la form actuellement designée peut etre abstraite, ca ne pose pas de probleme. Par contre, si la form actuellement designée herite d'une form abstraite, le designer va t'insulter. Enfin, toujours concernant le designer, il faut que la form de base ait un constructeur sans argument (private ou public qu'importe mais il faut qu'il soit present).

Un lien qui trainait dans mes bookmarks qui explique comment marche le designer de VS. Et un autre, qui fait un parallele avec le designer de WPF.

[Invité1]

Merci pour vos réponses.

J'avais pensé à crée une Form abstraite mais le soucis c'est que cette classe va se trouver dans une DLL donc j'aurais voulu eviter de la rendre dependante d'une Form.

Je vais continuer à plancher sur la question ou trouver une autre solution. Encore merci pour votre aide.

[Alikendarfen]

Bonjour,


Peut être pourrais tu utiliser le pattern MVC (Model View Controler).

Tu trouveras plein de littérature sur le sujet sur le net.

Dans le principe, cela permet à la fois de rendre indépendant et de faire fonctionner ensemble 3 choses :
- le modèle : de manière générale les données et fonctions métier.
- la vue : la représentation graphique des objets de ton modèle.
- le contrôleur : celui qui gère les interactions entre le modèle et la vue.

Dans la pratique, en .Net, tu peux facilement lier tout cela à l'aide des évènements et des fonctions déléguées.

Si tu implémentes une classe C dont différentes méthodes sont liées à ta Form par l'intermédiaire des évènements de la forme, tu peux sur la classe C définir tous les traitements que tu veux et faire comme si C participait de ta Form (car C implémente les méthodes correspondant aux évènements sur la Form).

[Invité1]

Alors j'ai tout de même essayé de faire un classe abstraite implémentant mon interface et héritant de Window (WPF) et ensuite de faire hériter la Window de mon programme de cette classe abstraite mais le compilateur me dit toujours que la classe base est differente.

Code de ma classe contenant une interface WCF dont je veux implémenter les callbacks dans ma fenêtre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[ServiceContract(CallbackContract = typeof(ITTO_Socket))]
public interface ITTO_Socket
{
    [OperationContract(IsOneWay = true)]
    void ReceiveOSC();
 
    [OperationContract(IsOneWay = true)]
    void InitializeConnection();
}
 
public abstract class TTO_Socket : Window, ITTO_Socket
{
    public abstract void ReceiveOSC();
 
    public abstract void InitializeConnection();
}

Code de ma fenêtre WPF :

Code :

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

1
2
3
4
5
6
7
public partial class Window1 : TTO_Socket
{
    public Window1()
    {
        InitializeComponent();
    }
}

Là je ne comprend pas tellement ou est le problème. Même en créant une classe n'héritant que de System.Windows.Window j'ai le même problème.

[SirJulio]

Salut,

c'est du à la "partialité" des classes pouvant etre designé : Sur une classe partielle, il faut repeter la classe de base dans tous les fichiers de declarations : voir ce thread.

Pour la classe abstract, par rapport à ce que je disais au dessus, le designer risque de t'embeter avec une window de base abstraite. Essaie plutot de faire un constructeur avec une portée protégé.

Bon courage.