Discussion :

[SirJulio]

Ok mais ça pose problème car justement je dois pouvoir l'appeler sans mettre en dur une classe.

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?

[Guulh]

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?

J'opine. Que ce soit en créant une variable (pointant sur un type), en créant une classe générique ou avec des #define, c'est pareil, non ? Dans les trois cas, il n'y a qu'une ligne à changer pour passer de l'un à l'autre.

[WebPac]

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?

Tout à fait, mais je ne le souhaite devoir le faire qu'une fois au tout début du projet et dans une partie spécifique au projet et non dans le code commun.
Les 2 projets ont beaucoup de partie commune (presque la totalité), sauf la déclaration du projet en elle même et la partie spécifique d'accès au tableur.

Je souhaite donc faire cette différenciation au lancement du projet, dans un code d'instanciation de l'application, je n'ai pas encore trouvé exactement où, j'ai pensé le mettre dans le constructeur statique de chaque classe fille afin de ne pas avoir à le mettre en dur au début du projet et que ce soit toujours appelé (exemple, si les classes sont réutilisées dans d'autres projets).

Dans la version 2005, la partie qui créait la form principale puis la lançait n'était pas dans un code généré automatiquement, dans la version 2008 avec XAML, cette partie est générée automatiquement, je pense qu'il existe un événement que je pourrais récupérer pour faire cette différenciation (si je ne la fais pas dans le constructeur statique).

[SirJulio]

Dans la version 2005, la partie qui créait la form principale puis la lançait n'était pas dans un code généré automatiquement, dans la version 2008 avec XAML, cette partie est générée automatiquement, je pense qu'il existe un événement que je pourrais récupérer pour faire cette différenciation (si je ne la fais pas dans le constructeur statique).

Pour le probleme de l'intialisation, attache toi à l'event StartUp de ton App, il sera appelé à l'instanciation de ton App. Dans ce callback, tu pourras assigner la bonne fille à une variables tableur.

[WebPac]

Pour le probleme de l'intialisation, attache toi à l'event StartUp de ton App, il sera appelé à l'instanciation de ton App. Dans ce callback, tu pourras assigner la bonne fille à une variables tableur.

En effet, j'ai trouvé en tatonnant dans le XAML de l'app pour trouver cet événement (espérons qu'ils rajoutent les évéments dans l'inspecteur d'objet XAML).

Le problème en utilisant les #if #else .. est que le #define n'a pas la portée du projet entier mais juste de l'unité dans laquelle il est définit.
Cela voudrait dire que pour toutes les unités communes, je devrais écrire #define _Excel pour compiler le projet pour Excel, puis toutes les changer pour compiler le projet pour OpenOffice, autant dire que ce n'est pas qu'une ligne et le travail serait à faire à chaque changement de projet.
A moins qu'il n'existe un moyen de le déclarer au niveau d'un projet mais je n'ai pas encore trouvé cette possibilité.

[SirJulio]

Le problème en utilisant les #if #else .. est que le #define n'a pas la portée du projet entier mais juste de l'unité dans laquelle il est définit.
Cela voudrait dire que pour toutes les unités communes, je devrais écrire #define _Excel pour compiler le projet pour Excel, puis toutes les changer pour compiler le projet pour OpenOffice, autant dire que ce n'est pas qu'une ligne et le travail serait à faire à chaque changement de projet.
A moins qu'il n'existe un moyen de le déclarer au niveau d'un projet mais je n'ai pas encore trouvé cette possibilité.

Le define peut se faire dans les propriétés du projet (build => conditional compilation symbols) pour une constante "projectwide". =)

[WebPac]

Le define peut se faire dans les propriétés du projet (build => conditional compilation symbols) pour une constante "projectwide". =)

Merci, je me disais bien aussi que ça devait être possible, reste à trouver où.

Il n'empêche qu'avec la solution des #if #else, il faut non seulement, déclarer le #using en tête de chaque fichier qui est succeptible d'utiliser une classe fille, mais aussi quand on souhaite compiler les 2 projets, on est obligé de faire une reconstruction complète, sans quoi, des unités sont compilées avec la mauvaise #using.
De plus, le jour où il y aurrait une nouvelle fille, PDF par exemple, il faudra reprendre toutes les unités communes pour rajouter un #else if pour mettre #using = PDF. Vous me direz, cela n'arrive rarement, c'est vrai, mais le but d'une unité commune, c'est de ne rien connaître des unités spécifiques et avec cette méthode, pré-procession, elles y sont toutes et à la compilation, il y en a 1.

Mise à part ce point, le fait qu'il faille reconstruire est quand même blocant.

Pour finir avec tous ces tests, avec des classes et méthodes génériques, je n'ai pas réussi à le faire fonctionner.

La meilleure solution trouvée pour l'instant est d'utiliser une fabrique méthode statique de la classe mère Tableur qui fait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    public abstract class Tableur
    {
        public static Type _Type;
 
        public abstract string Test();
 
        public static Tableur Factory()
        {
            if (_Type.IsSubclassOf(typeof(Tableur)))
                return Activator.CreateInstance(_Type) as Tableur;
            else
                return null;
        }
    }

Avec initialisation de la variable _Type, soit dans le constructeur statique dans chaque classe fille (problème car on ne peut pas appeler le constructeur statique lorsqu'on le souhaite, il s'appelle un peu quand il veut et en testant, je l'ai vu s'appeler trop tard).
Ou initialisation de la variable _Type dans l'événement Application_Startup de chaque projet.

Merci en tout cas à tous ceux qui ont participé au sujet d'avoir pris de leur temps et fait chauffer leurs neurones un 31 décembre.

Et bonne année à tout le monde !

[WebPac]

Salut,
j'ai trouvé une solution qui n'utilise pas la réflexion mais uniquement les concepts de la POO, je vous la donne pour information, elle utilise le Design Pattern Abstract Factory.

Dans la classe Tableur, déclarer une classe protégée abstraite Fabrique.
Surcharger cette classe Fabrique dans les 2 classes filles de Tableur, FabriqueXL et FabriqueOOo.
Déclarer une variable statique Fabrique dans la classe Tableur.
Faire une méthode d'initialisation qui crée la variable statique en FabriqueXL ou FabriqueOOo dans la partie Startup du projet (donc dans une partie spécifique).
Puis déclarer une méthode statique publique dans Tableur nommée Factory qui appelle une méthode virtuelle qui crée l'instance du Tableur.

Je ne sais pas si j'ai été clair. C'est un peu plus complexe que l'autre solution, mais ça n'utilise que les concepts de POO sans avoir besoin de réflexion.