Ce type de bogue "use after free" est très courant dans les applications Qt, et la solution est toujours la même: remplacer delete par deleteLater. C'est exactement pour ça que cette méthode existe.
Oui tout à fait, je l'ai pas encore écrit mais ça me semble tout aussi simple.
deleted2 2015-03-26 at 06:28amEdited by deleted2 On the 2015-06-08 at 11:10pm @Kevin -> suite à ta réponse, un objet défini comme ça :class Ladder: public QObject
{
public:
Ladder(QString name);
~Ladder();
...
private:
Q_DISABLE_COPY(Ladder)
...
};
alloué sur le heap, sans autre héritage, et qui utilise deleteLater(), c'est pas un problème ?
Sinon, après la problématique à laquelle répond deleteLater(), on se retrouve avec une autre : comment faire pour détruire sans souci quelque chose qui contient un QWidget ?
J'espère que comme ça, ça marche.
J'ai cherché sans succès une méthode de Q(Core)Application qui permette de broadcaster un event à tous les QObject créés par l'application.
Ca permettrait aux objets qui le souhaitent de s'enregistrer élégamment les uns auprès des autres, sans variable globale. Ca existe ?
Émettre un signal auquel les objets intéressés peuvent se connecter (avec un slot), ça ne te suffit pas?
Ca demande que l'émetteur connaisse l'adresse des destinataires. Idéalement, j'aurais aimé éviter. Je vais totu simplement procéder autrement, merci.
Dans mon idée, c'est aux destinataires de se connecter au signal de l'émetteur. (C'est comme ça que fonctionnent les signaux et slots Qt normalement.) Ainsi, l'émetteur "connaît" les destinataires dans le sens où il y a une liste des connections quelque part dans les membres privés de QObject, mais c'est géré à l'intérieur de Qt, ton code ne doit pas s'en occuper.
Mais peut-être qu'avec un exemple, je verrais mieux ce que tu veux faire?
deleted2 2015-03-27 at 09:03pmEdited by deleted2 On the 2015-06-08 at 11:10pm Bon, je m'y suis pris complètement autrement, d'une façon certainement plus Qt-compliant. J'essaye de me plier à la philosophie du truc.
pwic, j'ai un souci avec QCloseEvent, ou la manière dont on ferme une fenêtre. J'ai lu (et reeeelu) le tutorial d'une simple application, je ne vois pas ce qui cloche, et pourtant...
// Post a close event, which will cause MainWindow::closeEvent() to be called later
void MainWindow::on_buttonQuit_clicked()
{
// The event loop takes the ownership of the event and frees it
qApp->postEvent(this, new QCloseEvent;
}
Donc dans ma MainWindow, j'ai un bonton "quit" qui est censé quitter, en postant un QCloseEvent. Ca a l'air tellement simplissime que je ne vois pas ce qui cloche.
Je ne trifouille pas les flags de la mainwindow, je ne redirige rien vers ci ou ça, donc je ne sais pas vers où chercher ><
Une idée stp ?
Normalement, on utilise QCoreApplication::quit() pour quitter l'application.
Il faut appeler close() et ce sera Qt qui activera ton closeEvent et réagira en conséquence. Poster directement le QCloseEvent ne sert à rien, c'est seulement le mécanisme pour accepter ou rejeter la fermeture, mais la réception de l'évènement ne ferme rien, la logique est dans la méthode close.
attention, il est très dangereux d'effacer un QObject dans un slot, parce qu'il peut y avoir d'autres évènements en attente. Pour ça, QObject propose une méthode 
)
