Destructeur de classe - remise à NULL

Version imprimable

23/03/2007, 09h13
buzzkaido

Destructeur de classe - remise à NULL
Bonjour,

J'ai créé une classe d'objet.

Ces objets appartiennent à un conteneur.

Celui-ci ne sait pas forcement à l'avance si un de ses objet est déjà créé. Par exemple, si on demande d'ouvrir un objet, le conteneur verifie si il existe :

- si il existe, il l'ouvre
- sinon il le crée puis il l'ouvre

Donc pour savoir si un objet est déjà créé, lors de la création du conteneur, j'initialise la liste de pointeurs vers ses objets à NULL, comme ça je peux tester :
Code:

1 2 3 4 5 6 7 ouvrirObjet(*pObjet) { if (pObjet == NULL) pObjet = new cObjet(); pObjet->ouvrir(); }
Sauf que lorsque l'on detruit un objet avec delete, le pointeur vers cet objet ne revient pas à NULL...

Donc ma question : est-il possible de mettre ce pointeur à NULL à l'intérieur du destructeur ?

Un truc du genre this = NULL; mais en plus fin, puisque ça c'est interdit....

Merci !
23/03/2007, 09h19
Laurent Gomila

Citation:

Donc ma question : est-il possible de mettre ce pointeur à NULL à l'intérieur du destructeur ?

Non, mais rien ne t'empêche de le faire juste après le delete.
23/03/2007, 09h22
buzzkaido

Ah !

Evidemment, j'oubliais de preciser, le delete est automatique...

J'ai une procedure fermerObjet() qui peut etre appelée depuis l'objet lui-meme et qui à la fin fait execute :

delete this;

Donc lors de l'execution du destructeur, je ne connait pas le pointeur vers l'objet.

Du coup je pensais à une astuce du genre :

- à la construction, stocker un pointeur vers le pointeur de l'objet (!!!!)
- à la destruction, mettre la valeur pointée par ce pointeur à NULL

C'est un peu tordu, et ça n'a pas vraiement marché (je m'y suis peut-etre mal pris)
23/03/2007, 09h39
Laurent Gomila

Ca devient un peu bourrin là ;)

Tu pourrais détailler un peu plus ce que tu cherches à faire ? Je suis sûr qu'on peut trouver une solution plus élégante.

Ouais, je vais essayer d'etre plus clair :

J'ai un conteneur, qui contient 4 objets (par exemple)

du genre :
Code:

1 2 3 4 5 6 7 cConteneur { cObjet *pObjet1; cObjet *pObjet2; cObjet *pObjet3; cObjet *pObjet4; }
Le constructeur : (aucun objet n'existe)
Code:

1 2 3 4 5 6 7 8 cConteneur::cConteneur() { pObjet1 = NULL; pObjet2 = NULL; pObjet3 = NULL; pObjet4 = NULL; }
Le destructeur :
Code:

1 2 3 4 5 6 7 cConteneur::~cConteneur() { if (pObjet1 != NULL) delete pObjet1; if (pObjet2 != NULL) delete pObjet2; if (pObjet3 != NULL) delete pObjet3; if (pObjet4 != NULL) delete pObjet4; }
Ouvrir un objet :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 cConteneur::ouvrirObjet(uneCondition) { switch (condition) { case condition_1 : if (pObjet1 == NULL) pObjet1 = new cObjet(); pObjet1->ouvrir(); break; case condition_2 : if (pObjet2 == NULL) pObjet2 = new cObjet(); pObjet2->ouvrir(); break; etc ...... } }
Et dans cObjet : (cette méthode est appelée sous certaines conditions : fin du traitement...)
Code:

1 2 3 4 5 cObjet::fermer() { fermerDesTrucs(); delete this; }
Donc mon probleme, c'est que si le conteneur ouvre un objet et que celui-ci s'est fermé (+ détruit) tout seul, le conteneur n'est pas au courant qu'il doit le ré-créer avant de le ré-ouvrir.....

Et pour d'autres raisons, je voudrait éviter de stocker un pointeur vers le conteneur dans chaque objet (les objets peuvent changer de conteneur etc...)

Donc mon vrai probleme, c'est de tester l'existence d'un objet via son pointeur....

23/03/2007, 10h23
Laurent Gomila

Tu as une architecture pas facile à gérer, où la responsabilité des ressources est partagée entre le conteneur et la ressource elle-même. Un truc qui aiderait bien serait les pointeurs intelligents à base de comptage de référence, ça éviterait déjà d'avoir à gérer des dépendances partout. Avec boost::weak_ptr je crois même que tu peux être notifié lorsque le boost::shared_ptr lié est détruit, ce qui pourrait convenir dans ton cas.

Bien sûr la solution la plus simple serait qu'une seule classe ait la responsabilité entière des ressources, mais apparemment ce n'est pas possible dans ton cas.

PS : delete NULL est tout à fait valide, pas besoin de tester le pointeur.
23/03/2007, 10h30
Patriarch24

Citation:

Avec boost::weak_ptr je crois même que tu peux être notifié lorsque le boost::shared_ptr lié est détruit, ce qui pourrait convenir dans ton cas.

Pour être exact, suivant la méthode utilisée pour accéder à l'objet via un weak_ptr (construction de shared_ptr avec passage de paramètre du weak_ptr, ou utilisation de la fonction weak_ptr::lock), tu auras une exception (bad_weak_ptr) ou un pointeur nul (shared_ptr::get() == 0) lors de la tentative d'accès à l'objet déjà détruit.
23/03/2007, 10h38
Startux
pourquoi tu fais pas une fonction qui ferai à peu près ça :
Code:

1 2 3 4 5 6 CContainer::liberer(*Objet) { Objet->fermer(); Objet = NULL; }
non ? :mouarf:

:lahola:
- Hé dis t'as vu Travail quelque part ?
- Non, moi je suis en vacances...
23/03/2007, 10h50
buzzkaido

Merci, je vais regarder du coté de boost....

@Startux :

Si si, je fais ça aussi, mais dans le cas où c'est le conteneur qui détruit l'objet.
Et dans ce cas, pas de soucis.

Mon soucis, c'est lorsque l'objet se détruit lui-même !

(comme dans les films, une fois que l'ordinateur central a déclenché l'auto-destruction du vaisseau, tout le monde est dans la merde !!)
23/03/2007, 12h00
Ulmo
Citation:
Envoyé par buzzkaido

Code:

1 2 3 4 5 cObjet::fermer() { fermerDesTrucs(); delete this; }
Ca me parait vraiment bizzare, un objet qui appelle son propre destructeur...
En particulier, l'objet existe encore juste après puisqu'on est dans une de ses méthodes.
23/03/2007, 12h04
Laurent Gomila

Citation:

Envoyé par Ulmo

Ca me parait vraiment bizzare, un objet qui appelle son propre destructeur...
En particulier, l'objet existe encore juste après puisqu'on est dans une de ses méthodes.

Il arrive qu'on ait besoin que des objets s'auto-détruisent, notamment lorsqu'ils sont les seuls à savoir quand le faire. Tant qu'il n'y a aucune référence à une fonction ou une variable membre après la destruction, rien n'empêche de la faire de cette manière.

Salut,

Ceci dit, pourquoi ne pas déléguer la destruction de l'objet au conteneur, et non à l'objet:question:

Code:

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
 
class cConteneur
{
    cObjet    *pObjet1;
    cObjet    *pObjet2;
    cObjet    *pObjet3;
    cObjet    *pObjet4;
    public:
        void Detruire(cObjet* obj);
        //variante
        void Detruire(unsigned int ind);
};
void cConteneur::Detruire(cObjet* obj)
{
    // profitons de ce que obj dispose encore de l'adresse
    // vers laquelle il pointait apres sa destruction pour s'éviter quelques
    //lignes de code (il est paresseux, le koala :P:S)
    delete obj;
    if(obj==pOjet1)
        pObjet1=NULL;
    if(obj==pOjet2)
        pObjet1=NULL;
    if(obj==pOjet3)
        pObjet1=NULL;
    if(obj==pOjet4)
        pObjet1=NULL;
}
void cConteneur::Detruire(unsigned int ind);
{
    switch(ind)
    {
        case 1: 
            delete pObjet1;
            pObjet1=NULL;
            break;
        case 2: 
            delete pObjet2;
            pObjet2=NULL;
            break;
        case 3: 
            delete pObjet3;
            pObjet3=NULL;
            break;
        case 4: 
            delete pObjet4;
            pObjet4=NULL;
            break;
    }
}

D'autant plus que, tu semble malgré tout te contredire quelque peu:

Tu semble dire qu'à l'ouverture, l'objet peut éventuellement etre préexistant, mais qu'il devrait d'office etre détruit à la fermeture...

Alors, la question à cinq cents: comment l'objet pourrait il etre préexistant:question: (ou alors, il y a du code qui manque :P)

23/03/2007, 13h03
Ulmo

Citation:

Envoyé par Laurent Gomila

Il arrive qu'on ait besoin que des objets s'auto-détruisent, notamment lorsqu'ils sont les seuls à savoir quand le faire. Tant qu'il n'y a aucune référence à une fonction ou une variable membre après la destruction, rien n'empêche de la faire de cette manière.

N'est-il pas préférable d'utiliser une méthode ::destroy() qui fasse le ménage, et de l'appeler depuis le destructeur (sans effet si le ménage est déjà fait) ?

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?
23/03/2007, 13h18
Laurent Gomila

Citation:

Ceci dit, pourquoi ne pas déléguer la destruction de l'objet au conteneur, et non à l'objet

Apparemment l'objet peut changer de conteneur en cours de route, ce n'est donc pas ce dernier qui doit gérer la durée de vie de l'objet.

Citation:

N'est-il pas préférable d'utiliser une méthode ::destroy() qui fasse le ménage, et de l'appeler depuis le destructeur (sans effet si le ménage est déjà fait) ?

Et le destructeur, qui l'appelle ?

Citation:

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?

On parle bien sûr d'instances allouées dynamiquement... Parce que "delete this" sur une instance locale à une portée, ça ne ferait pas exactement ce qu'on veut ;)
23/03/2007, 13h21
koala01

Citation:

Envoyé par Ulmo

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?

Pas quand il a été créé avec new...

Le but des pointeurs est, justement, de permettre la persistance de l'objet en dehors de la portée où il a été créé, mais nécessite qu'un systeme quelconque soit mis en place pour retrouver l'adresse à laquelle se trouve l'objet ;)

En fait, soyons clairs: la variable de type pointeur est, effectivement, détruite quand on sort de portée, mais l'objet pointé par le pointeur continue, lui, à exister ;)
23/03/2007, 13h42
Ulmo
Ouioui, il y a des choses qui survivent à la portée.

Mais celui qui appelle la méthode qui détruira l'objet pourrait aussi bien le détruire lui même. C'est à dire remplacer :
Code:

1 2 3 4 5 6 7 cObjet::fermer() { fermerDesTrucs(); delete this; } ... UnCObjet->fermer();
par:
Code:

1 2 3 4 5 6 cObjet::~cObjet() { fermerDesTrucs(); } ... delete UnCObjet;
La sule différence que j'y voit est le nom de la fonction qui est peut-être moins clair.

Citation:

Envoyé par Laurent Gomila

Apparemment l'objet peut changer de conteneur en cours de route, ce n'est donc pas ce dernier qui doit gérer la durée de vie de l'objet.
(snip)

Si tel est le cas,comme on peut envisager que tous les conteneurs fonctionnent relativement de la meme facon, il suffit, quand le pointeur change de conteneur, de mettre le pointeur dans le conteneur d'origine à null, sans passer par Detruire ;)

Code:

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
 
// renvoie le pointeur et le supprime du conteneur
cObjet* cConeteur:zerote(unsigned int ind)
{
    cObjet* temp=NULL;
    switch(ind)
    {
        case 1: 
            temp=pObjet1;
            pObjet1=NULL;
            break;
        case 2: 
            temp=pObjet2;
            pObjet2=NULL;
            break;
        case 3: 
            temp=pObjet3;
            pObjet3=NULL;
            break;
        case 4: 
            temp=pObjet4;
            pObjet4=NULL;
            break;
    }
    return temp;
}
//place un objet dans le conteneur à la place ind
void cConteneur::Place(cObjet* obj, unsigned int ind)
{
/* il sera vraissemblablement utile de vérifier s'il ne faut pas
   détruire l'objet avant de placer le nouveau ;) 
   ou, au minimum, un test de faisabilité ;) */
    switch(ind)
    {
        case 1: 
            pObjet1=obj;
            break;
        case 2: 
            pObjet2=obj;
            break;
        case 3: 
            pObjet3=obj;
            break;
        case 4: 
            pObjet4=obj;
            break;
    }
}
// peut etre utilisé sous une forme proche de (orig et dest étant des 
// cConteneur ;) )
dest.place(orig.zerote(3),2);

23/03/2007, 13h51
buzzkaido

Hé ben !

Je vois que ma question en suscite bien d'autres....

En fait, le vrai probleme de départ, c'est pour le conteneur :

Au moment où il doit ouvrir un objet, comment savoir s'il doit d'abord le créer ?

Car 3 cas existent :
- c'est la premiere fois que l'objet est ouvert, il faut le créer
- l'objet est deja créé, il faut juste l'ouvrir
- l'objet a déjà été ouvert, mais il s'est fermé tout seul, il faut le re-créer

(on peut ré-ouvrir un objet déjà ouvert)

Le vrai souci, c'est de tester si l'objet existe ou pas (si on doit le créer ou pas) car je voudrais éviter de mettre une série de booléen dans le conteneur (du genre bObjet1Ouvert, bObjet2Ouvert....) et de devoir les tenir à jour...

(il y a différentes raisons à cela)

Le plus simple, je crois, va finalement être de créer un "superObjet" qui contient lui-même uniquement 2 choses :
- l'objet
- un booléen bCréé

Afin de determiner si l'objet est crée ou non... sauf que je trouve ça un peu lourd :-)
23/03/2007, 13h58
Laurent Gomila

C'est quoi le contexte d'utilisation ? Tu peux mettre des noms réels sur Conteneur et Objet pour qu'on situe mieux le problème ?
23/03/2007, 13h59
koala01

Je crois qu'avant d'essayer d'aller plus loin, il nous faudrait d'avantage de renseignements, entre autres, ne serait-ce qu'un(e partie de) code minimum compilable mettant en scene l'objet et le conteneur, de manière à savoir ce qu'il en est...

Au pire, si tu nous expliquait déjà en quoi consiste le fait qu'un objet soit "ouvert" ou "fermé", ce qu'il permet quand il est ouvert, et ce qu'il permet quand il est fermé, et un ordre d'idée sur l'application que tu tentes de mettre au point :question:

Désolé de poser ces questions, mais, ma boulle de cristal est en panne... et, si tu veux une réponse efficace, il faut nous aider à t'aider ;):D

EDIT grilled :P
23/03/2007, 14h12
buzzkaido

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....
23/03/2007, 14h13
buzzkaido

D'ailleurs, si vous voulez voir un apreçu de la GUI, regardez mon avatar :-)
23/03/2007, 14h16
koala01

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:question:
23/03/2007, 14h48
buzzkaido

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...
23/03/2007, 14h59
NewbiZ

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é).
23/03/2007, 15h04
buzzkaido

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 !
23/03/2007, 15h16
NewbiZ

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).
23/03/2007, 15h27
buzzkaido

Hé hé !

Encore mieux, effectivement...

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:

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 :oops:)

23/03/2007, 15h31
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 !
23/03/2007, 15h38
koala01

Citation:

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 ;)
23/03/2007, 15h41
buzzkaido

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...
23/03/2007, 15h53
koala01
si tu veux que le contenu dise à un moment "détruit moi", il te suffit de faire un

Code:

parent->Detruit(this);

(mais pas dans le destructeur du contenu, évidemment ;)[/CODE]
avec une fonction Detruit dans le conteneur ressemblant à
Code:

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 :oops:
23/03/2007, 15h59
buzzkaido

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....

:yaisse2:

Fuseau horaire GMT +2. Il est actuellement 21h04.