Discussion :

[Invité]

Bonjour.
J'ai une application (Delphi 6) avec une seule fiche principale qui comprend un composant MediaPlayer. Il y a différentes procédures "événementielles" et une "sous-procédure" appelée à partir des précédentes (entrées-sorties USB via un adaptateur). J'ai constaté le phénomène curieux suivant : si je ferme le MediaPlayer (Close après Stop et avant fermeture de la fenêtre principale) à partir de ma procedure d'entrée-sortie (suite à une I/O Error générée par l'adaptateur) afin de "tout" quitter, il y a souvent une disparition partielle de la fenêtre, l'image se met à "scintiller" et le système se bloque, il ne me reste plus que le gestionnaire de tâches ; ce phénomène disparaît si je ferme ma fenêtre sans fermer le MediaPlayer (?). Ma question est : est-ce que la fermeture d'une fiche (par close) ferme implicitement et PROPREMENT également ce type de composant qui y est inclus ?
Merci d'avance ...

[Invité]

"Disparition partielle de la fenêtre" correspond en fait à la non-visibilité de composants TImage qui se retrouvent cachés ...

[ShaiLeTroll]

Le Close ne libère pas forcément la fenêtre

Le cas d'une fenêtre principale est particulier !
Sa fermeture provoque l’arrêt du programme
Cela appel le destructeur de la fenêtre donc celui du TMediaPlayer
Par contre, le TMediaPlayer n'appel pas forcément Stop puis Close par contre sa mémoire est libéré et ses handles aussi

Et il faut faire attention à ce que l'on fait depuis un gestionnaire d'évènement
j'ignore le lien avec ton module IO

On pourrait penser que la boucle RUN ne passe plus les WM_PAINT à la MainForm d'où l'absence d'affichage
Est-ce du blanc comme lors d'un blocage ou alors on voit les traces d'anciens éléments ?


le cas d'une fenêtre secondaire (teste ce mode aussi !)
Pense au caFree dans le OnClose comme Action, cela peut changer le comportement
Si c'est fenêtre modale, tu libères explicitement la fenêtre après le ShowModal

Sans un minimum de code difficile de répondre plus !
As-tu réussi de le reproduire dans un autre projet SANS le module IO en simulant un faux plantage

[Invité]

Merci de ta réponse ... Le problème est que c'est la première (et peut-être la dernière ...) fois que je développe avec des modules USB (FTDI et IOWarrior), je trouve que l'USB dans ce contexte c'est de la m... (désolé pour la netiquette). Le IOW n'a pas de reset donc en cas de plantage, Unplug or Pray. Le FTDI (connu dans le cadre USB MOD4 et assimilés, maintenant remplacés) a un reset ; effectivement après un reset le module n'est plus reconnu et génère une erreur IO, je voulais donc carrément fermer le programme car après un reset de toute manière tout est inactif. Gag, le pilote 2.0.8 qui marchait à peu près (le dernier pour 2000) n'est plus en ligne, le 2.0.6 génère en cas de reset une erreur "débranché sans éjecter" (!), il ne pousse pas le vice à rajouter l'image des "lapins crétins" Bref, le port parallèle quant à lui ne fait pas de feedback pour SAVOIR SI les choses se sont bien passées ou non, elles se passent de toute manière BIEN. Et à ceux qui diront qu'il n'y a plus de port parallèle sur les bécanes, les sociétés d'Extrême Orient se feront un plaisir de te vendre une carte fille