Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.
Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).
Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.
Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.
Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).
Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.
Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.