Destructeur de classe - remise à NULL

**buzzkaido** · 23/03/2007, 14h12

Ben c'est pour un système de GUI personnalisé...

Un conteneur peut etre une fenetre, ou un conteneur de controles...

Un objet peut etre un bouton, une liste déroulante....

Les conteneurs peuvent contenir des conteneurs, puisqu'ils sont eux-meme des objets.

Les objets peuvent etre fermés par le conteneur (par ex. si un traitement se termine, on ferme la barre de progression, si on ferme le conteneur, on ferme tous ses objets) ou par eux-meme (une fenetre peut se faire fermer par elle-meme, une liste peut se fermer une fois que l'on a fait une selection)

Vu qu'il y a du drag'n'drop et 2-3 autres trucs, les objets peuvent changer de conteneur dynamiquement.

Les pointeurs vers les objets d'un conteneur sont stockés dans un vecteur du conteneur.

Un objet peut etre ouvert 2 fois de suite, puisque si on a un bouton pour ouvrir une fenetre ou une liste, on peut cliquer dessus plusieurs fois....

Et le but est d'avoir en mémoire un minimum d'instances d'objets à la fois :

Si une fenetre contient 15 objets, ceux-ci seront créés dynamiquement à l'ouverture de la fenetre, et detruit dynamiquement à sa fermeture.

Une grosse partie du code est deja écrit et fonctionne tres bien, le dernier soucis c'est lorsque l'on tente de ré-ouvir un controle qui s'est détruit lui-meme, le conteneur n'est pas au courant qu'il faut le recréer....

**buzzkaido** · 23/03/2007, 14h13

D'ailleurs, si vous voulez voir un apreçu de la GUI, regardez mon avatar :-)

**koala01** · 23/03/2007, 14h16

Ben, dans ce cas, empeche l'objet de se détruire lui-meme...

Délègue la destruction au conteneur, ainsi que je le disais plus haut... excepté pour la fenetre principale, bien sur

Les seules choses qu'un objet doive pouvoir faire sur lui meme, c'est s'ouvrir et se fermer... (se remplir en cas de besoin)

Ceci dit, pourquoi ne pas utiliser une bibliotheque GUI existante, au lieu de vouloir réinventer la roue

**buzzkaido** · 23/03/2007, 14h48

Je ne réutilise pas de GUI existante car c'est pour un cas tres specifique : plugin intégré dans un logiciel, et les seuls bibliotheques existantes ne me satisfont pas du tout (trop limitée) ou sont payantes

De plus, c'est pas tres compliqué de faire une GUI : tout le code fonctionne tres bien.

Le souci, c'est effectivement pour la fenetre principale, qui est elle aussi contenue dans un conteneur (le plugin) et pour les fenetres enfants : elles ont des boutons "close" qui devrait les detruire, pour eviter de les garder en memoire.

Et aussi pour d'autres controles : les listes déroulantes ou les menus qui apparaissent en pop-up... il y en a beaucoup de differents, je ne veux donc pas les garder tous en memoire. Et ils peuvent se detruire tout seul (timeout par exemple)

Et aussi : le codage de tout le reste s'est tres bien passé, et là je tombe sur un probleme d'architecture ou d'implémentation (je sais pas trop)
J'aimerais le résoudre pour apprendre...

**NewbiZ** · 23/03/2007, 14h59

Pourquoi ne pas fonctionner par messages ? Les actions sur les fenêtres lancent des messages, ceux ci sont stockées dans une pile, puis a chacun de filtrer les messages qui l'intéressent. Il te suffira alors de bloquer au niveau du conteneur les messages de fermeture des fenêtre. C'est un système adopté dans beaucoup de GUI (en résumé).

**buzzkaido** · 23/03/2007, 15h04

Effectivement !

Je fonctionne deja avec un systeme de messages, mais ceux-ci ne gerent pas les destructions/fermetures...

En y reflechissant un peu, il suffirait effectivement que lors de son auto-destruction, un controle envoit un message "JeMeSuisDetruit" pour que le ou les conteneurs concernés se mettent à jour... et mettent le pointeur vers cet objet à NULL...

Bien vu !

**NewbiZ** · 23/03/2007, 15h16

Plutot que d'envoyer un message "Je me suis détruit", la plupart des GUI envoient un message "On veut que je me détruise" :

1) Le conteneur garde la main-mise sur ses objets, et les détruits comme bon lui semble.

2) Plus de souplesse, le conteneur peu décider : non tu ne te détruira pas parcequ'il y a des fenêtres qui dépendent de toi. (par exemple).

**buzzkaido** · 23/03/2007, 15h27

Hé hé !

Encore mieux, effectivement...

**koala01** · 23/03/2007, 15h27

Une petite synthèse

La classe fenetre, elle ne peut etre détruite que par le plugin, soit...
Les objets ne se détruisent pas tous seuls, mais détruisent leur contenu s'il échoit
les objet ont un booléen "visible" qui indique s'ils sont visibles ou non (je préfère le terme visible à ouvert )
les conteneurs détruisent les objet quand c'est nécessaire:
- quand visible passe à false (supression des objets contenus )
- quand ils sont eux-meme détruits

Tu aurais donc les classes Objet et Conteneur ressemblant à ceci:

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
 
class Conteneur;
class Objet
{
    private:
        // il est intéressant de garder une référence sur le conteneur parent;) 
        Conteneur* m_parent;
        bool visible;  //surtout utile pour les conteneurs... mais bon
        (autres informations utiles aux objets)
    public:
        Objet(Conteneur* parent):m_parent(parent){}
        ~Objet(){/* ne s'occupe que de SES propres membres ;) */}
        bool IsVisible()const{return visible;}
        void Open(){visible=true;}
        vois Close(){visible=false;}
};
class Conteneur:public Objet
{
    private:
        std::vector<Objet*> m_enfants;
        bool m_visible; // appartient en fait à la classe Objet ;)
    public:
        /* il me semble intéressantde 
        Conteneur(Conteneur* parent):Objet(parent){}
        ~Conteneur()
       {
          /* pour détruire le contenu du conteneur ;) */
           Close();
       }
        void Close()
        { 
            /*ferme le conteneur, détruit ce qu'il contient, mais ne le détruit 
               pas*/
             Objet::Close();
             for(unsigned int i=0;i<m_enfants.size(); i++)
                 delete m_enfants[i];
             m_enfants.clear();
        }
        void Open()
        {
             //c'est ici que les objets sont créés ;)
        }
        void Remove(int ind)
        {
            //retire l'objet du tableau, sans le détruire
            //considère que tu as déjà récupéré l'objet en question ;)
            m_enfants.erase(m_enfants.begin()+ind);
        }
        //variante
        void Remove(Objet* obj)
        {
             int i=0;
             while(i<m_enfants.size() && m_enfants[i]!=obj)
                 i++;
             Remove(i);
        }
        //ajoute un objet au tableau (index facultatif: l'ajout se fait alors à la         
        // fin du tableau)
        void Add(Objet* obj,int ind=-1)
        {
             if(ind==-1)
                 m_enfants.push_back(obj);
             else
             {
                     m_enfants.insert(m_enfants.begin()+ind,obj);
             }
        }
}

(code non testé donc pouvant contenir une ou l'autre erreur

)

**buzzkaido** · 23/03/2007, 15h31

Ah, oui !

Mais...

Pour moi visible != ouvert

On peut etre ouvert mais invisible à sur ecran : traitement de fond, bouton "disablé"... etc

Sinon, pour le reste, c est exactement ce que j ai deja codé !

Merci pour tout !

**koala01** · 23/03/2007, 15h38

Envoyé par buzzkaido

Ah, oui !

Mais...

Pour moi visible != ouvert

On peut etre ouvert mais invisible à sur ecran : traitement de fond, bouton "disablé"... etc

Sinon, pour le reste, c est exactement ce que j ai deja codé !

Merci pour tout !

Hé bien, si ouvert!=visible (car, pour etre visible, il faut qu'il soit ouvert), rajoute simplement un booléen m_open et les méthodes IsOpen(), IsClosed(), SetVisible SetNotVisible()... Et le tour est joué

Mais l'idée de base, de toute manières, que c'est le conteneur qui efface le contenu, et que le contenu n'a aucun droit sur sa propre existance

**buzzkaido** · 23/03/2007, 15h41

Le soucis, c'est que open = créé, donc si fermé, m_open n'existe pas !

Bien d'accord avec l'idée de base....

Mais par la suite, j'ai trouvé que dans quelques cas, c'est bien pratique de se detruire soi-meme... et c'est reglé par un message !

Comme quoi c'était tout bete, et en plus on peut generalisé à des systèmes "imbriqués" même s'il ne s'agit pas d'une GUI...

**koala01** · 23/03/2007, 15h53

si tu veux que le contenu dise à un moment "détruit moi", il te suffit de faire un

Code :

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

parent->Detruit(this);

(mais pas dans le destructeur du contenu, évidemment

[/CODE]
avec une fonction Detruit dans le conteneur ressemblant à

Code :

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

1
2
3
4
5
6
7
8
 
void Conteneur::Detruit(Objet* obj)
{
    Remove(obj);
    delete obj;
    //juste par habitude
    obj=NULL;
}

Bien que j'aie un doute sur ce point précis

**buzzkaido** · 23/03/2007, 15h59

Ben oui !!!

Comme quoi, avoir l'avis des autres ça peut aider, surtout que j'ai deja cette fonction implémentée (pour la destruction d'un conteneur, pour qu'il puisse detruire tout son contenu)

Et si je l'implemente dans une classe à part, je peut en faire deriver le plugin afin de détruire aussi la fenetre principale de cette façon....

Destructeur de classe - remise à NULL

C++

Discussions similaires

Partager

Partager