Simplification d'écriture

Bonjour.

Bonjour à tous,

je suis en train de réaliser une classe de manipulation d'Excel avec
OLE sous Builder, et j'ai un souci:
[...]
J'ai essayé de passer un pointeur Excel* depuis la classe initiale
vers les classes inférieures, et à chaque fois que XLCells change par
exemple, le pointeur XLCells Excel::Cells* de Excel change également,
mais également XLFont Excel::Font*, puisque XLFont est lié à XLCells.

[1/2HS (?) : mapping C++ d'une structure de données propriétaire
Windows/OLE]

Il me semble bien d'après votre description que les objets Excel sont
reconstruits et donc réalloués lors des modifications, ce qui fait que seul
le pointeur d'entrée reste valide.

Dans ces conditions, il me paraît inévitable de ne pas conserver les autres
pointeurs dans votre représetnation externe, mais à la place un mécanisme de
"handles" (ie: identifiants aux valeurs subies) qui vous permette de les
reconstruire à la demande par réinterrogation de l'objet Excel d'entrée (la
feuille). Les pointeurs ne sont alors valides que le temps d'une opération
d'accès.

Ca ne paraît pas trop compliqué à faire : un objet cellule (ou plage de
cellules) peut contenir un Handle sous forme de chaîne (ou quadruplet
d'entiers) à base de Lx:Cy (ou Lx1:Cy1/Lx2:Cy2), et pour les attributs vous
faites comme vous voulez.

Hope It Helps,

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Michael wrote:

je suis en train de réaliser une classe de manipulation
d'Excel avec OLE sous Builder, et j'ai un souci:

j'ai décomposé les classes suivantes:

class Excel //Sommet de la hiérarchie
class XLSheets //Pour gérer les feuilles
class XLSheet //Feuille courante
class XLCells //Cellules sur lesquelles on travaille
class XLFont //Gestion de la police... des cellules choisies

Chacune de ces classes garde un pointeur sur la classe
inférieure.

C-à-d les objets dont elle est propriétaire (rélation « aUn ») ?
(La plupart du temps, quand on parle d'« inférieur », il s'agit
d'héritage. Mais alors, il n'y aurait pas de pointeurs.)

Par exemple, si je veux ajouter une nouvelle feuille, puis
remplir des cellules de la feuille créée:

Excel->XLSheets->Add("nom_feuille"); //Sheets::XLSheet * Sheet est connu
Excel->XLSheets->Sheet->Cells->Define(1,1,5,5); //On a choisi un tableau
de 4x4
Excel->Sheets->Sheet->Cells->Set_Value("toto");

Ce que je voudrais, c'est stocker des pointeurs dans la classe
Excel, afin d'accéder directement à la feuille choisie, aux
cellules définies ou bien à la classe de Font, de sorte qu'on
aurait, pour le même exemple que précédemment:

Excel->XLSheets->Add("nom_feuille"); //Sheets::XLSheet * Sheet est connu
Excel->Sheet->Cells->Define(1,1,5,5); //On a choisi un tableau de 4x4
Excel->Cells->Set_Value("toto");

Je ne suis pas sûr que ce soit une bonne itée, mais enfin...

J'ai essayé de passer un pointeur Excel* depuis la classe
initiale vers les classes inférieures, et à chaque fois que
XLCells change par exemple, le pointeur XLCells Excel::Cells*
de Excel change également, mais également XLFont Excel::Font*,
puisque XLFont est lié à XLCells.

Une autre solution serait de passer par Excel chaque fois pour
la contruction aussi, c-à-d :

Excel->AddSheet( "nom_feuille" ) ;
Excel->DefineCell( 1, 1, 5, 5 ) ;

Chaque fois, Excel renvoie à l'objet qui convient ; la fonction
dans l'objet renvoie alors un pointeur à l'objet qu'il aura
créé, que l'objet Excel peut stocker comme il veut.

Mais je me heurte à des problèmes suite aux inclusions, car je
suis obligé d'inclure à chaque fois le H de Excel, et j'arrive
pas à compiler tout le bouzin...

Au niveau des .h, il ne doit pas y avoir de problème : une
déclaration anticipée de classe en tête ferait l'affaire. Mais
évidemment, si c'est l'objet appelé qui doit faire la mise à
jour de l'objet appelant, il faudrait inclure Excel.h dans les
sources de tous les autres objets.

De point de vue de la conception, je n'aime pas. Ça fait des
cycles dans les dépendances -- je préfère qu'une classe qui
fournit une service n'a pas à connaître ses clients. Inversion
de l'appel qui s'en suit introduit des couplages qui pourraient
poser des problèmes par la suite.

Si quelqu'un voit une solution pour mon problème, je suis
preneur ;)

Déjà, j'essaierais d'éviter l'inversion de l'appel. Sans
l'introduction des classes supplémentaires en pagaille, elle
augmente le couplage d'une façon inacceptable. Mais même plus
fondamental, je me poserais la question s'il faut réelement
ramener toutes les informations vers la classe propriétaire. A
priori, si tu as introduit un gestionnaire des sheets entre
Excel et les feuilles mêmes, il doit bien avoir une raison ; si
Excel doit aussi gérer les feuilles, à quoi sert le
gestionnaire ? De la même façon, comment est-ce que les feuilles
peuvent gérer proprement les cellules, si Excel si mèle aussi ?

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34