Discussion :

[Invité]

Bonjour.
Il est impossible de fermer un programme (comprenant une seule fiche) dans la routine "OnCreate" par "[NomDeLaFiche].Close;", ni sous W2000, ni sous XP. L'instruction "[NomDeLaFiche].Release;" fonctionne de manière "sale", c'est-à-dire qu'après exécution il est impossible de recompiler l'application : l'exécutable reste "ouvert". Enfin l'instruction "[NomDeLaFiche].Free;" plante méchamment ...
La seule méthode qui SEMBLE fonctionner proprement est "Application.Terminate ;" !
Je m'explique : je dois initialiser un périphérique USB et en cas d'absence de celui-ci quitter le programme sans autre forme de procès.
Avez-vous aussi déjà remarqué ce problème ?

[SergioMaster]

Bonjour,

je n'appellerai pas ça un bug de Delphi (AMHA ce comportement est "valable" avec toutes les versions), il s'agit plutôt une mauvaise utilisation du OnCreate.
Si le code se trouvait dans le OnShow ou le OnActivate de la fiche le problème ne se poserait pas (du moins pas de la même façon)

Schéma :
dans le OnCreate initialiser le périphérique
dans le OnActivate si périphérique non initialisé Close;

[Invité]

pour la réponse rapide. Mais on peut voir cela comme on veut : il y a 30 ans, chez un grand fabricant de matériel et logiciels, il n'y avait pas de bugs, seulement des "features" ...

[foetus]

Fais gaffe à OnActivate: cette méthode est appelée lorsqu'on l'application récupère le focus (appeler ou pas )

Colle un Application.Terminate dans le OnShow et assure toi que dans le OnClose l'action est caFree c'est plus sûr

[Invité]

Voilà, j'ouvre mon périphérique USB dans ma routine en mode "OnCreate", en cas d'échec je termine par "ApplicationTerminate" ; cela fonctionne sauf ... que mon programme est passé dans le second onglet, celui des processus, dans le gestionnaire des tâches. Et donc impossible de recompiler pour modifications avant d'avoir arrêté ce processus, qui au passage doit "bouffer" des ressources pour rien ! Comment faire pour terminer "proprement" ? PostMessage(Self.Handle, 16, 0, 0) ne marche pas non plus. A moins que tout ceci ne soit lié à la dll de contrôle de l'interface USB qui aurait "des problèmes" ?
Une autre curiosité est que des "OnActivate" et "OnDeactivate" définis via les événements de la fiche principale ... sont ignorés, maintenant que ma routine d'initialisation est en mode "onCreate" : il faut que je mette "Application.On(de)activate:= ..." dans ladite routine d'initialisation. Bizarre ... Auparavant, quand ma routine d'initialisation était définie dans l'événement "OnActivate", cela marchait et je redéfinissais l'événement OnActivate dans la routine. OnDeactivate n'a jamais marché via la gestion d'événements de la fiche principale !
J'attends vos suggestions !

[exoseven]

au pire utilise un timer que tu actives dans onCreate, ou tu cré un message personnalisé et tu l'envoie avec PostMessage (pas SendMessage qui est bloquant) depuis ton create cela devrais suffire je pense

[Invité]

Désolé, je crois devoir dire en définitive que mon système en entier est bogué ! Je ne vois plus que 2 solutions :
1) Changer de langage, mais 20 ans de Delphi laissent des traces ...
2) Virer mon interface USB et repasser au bon vieux port parallèle pour ma commande. Au moins celui-ci n'est jamais déconnecté ...
Au passage j'ai posé la même question (sans trop d'espoir) sur le forum du fabricant de l'interface ... Il diffuse aussi le composant HID du projet Jedi, que j'ai essayé également : il marche bien mais il met 2 secondes sous XP à détecter la déconnexion !
Et pour ajouter encore un peu à la folie : j'ai repris ma unit, dans laquelle le programme se termine par (fiche).close dans la routine d'initialisation, je l'ai copiée vers une autre version de l'application qui lance l'initialisation par OnActivate, et j'ai supprimé toutes les références au MediaPlayer qui se trouvait dans la première (étant entendu que celui-ce ne devait être ouvert qu'en cas de succès de la connexion). Et là ... aucun problème pour terminer l'application en cas de non-connexion, et rien ne reste dans le TaskManager. Donc j'ai refait un essai avec la même astuce dans la première application. Je lance mon appli par double-clic sur l'exe dans l'explorateur et je vois ... un rectangle grisé de la taille de ma fiche, le surlignement de l'exe scintiller comme un champ de force dans un film de SF et le programme ne s'arrête pas, jusqu'au moment ou j'ouvre le gestionnaire des tâches, et là il se termine sans que je ne fasse rien ! (il a dû avoir peur ). Bref mes problèmes proviennent apparemment d'une interaction entre PLUSIEURS bugs (la combinaison qui tue !) et là je crois que c'est sans espoir.
Merci quand même ...

[Andnotor]

Il y aurait toujours la possibilité de lancer un ExitProcess mais pourquoi ne pas faire cette initialisation avant la création de la fiche ?

... Il diffuse aussi le composant HID du projet Jedi, que j'ai essayé également : il marche bien mais il met 2 secondes sous XP à détecter la déconnexion !

La notification se fait via WM_DEVICECHANGE et chaque application la traitant peut passer un certain temps à la finalisation. Il n'est pas surprenant qu'il y ait un certain délai.

[SergioMaster]

Bonjour,

mais pourquoi ne pas faire cette initialisation avant la création de la fiche ?

C'est ce que j'allais proposer ce matin après réflexion.
Nombre de mes projets commencent par le chargement d'un datamodule qui se charge (entre autres) de vérifier un certain nombre de condition avant de lancer la fiche principale. C'est le projet lui même qui crée ou non le/s fiche/s (pas la peine de créer une fiche inutile pour la fermer ensuite)
pour cela if faut juste modifier le source du projet, un peu comme ce qui se fait pour un splashscreen

[Invité]

Méthode brutale pour arrêter dans un "OnCreate" : Halt(0) ; ferme sans laisser de traces.
Le reste de mes problèmes proviennent apparemment du MediaPlayer : en cas d'erreur d'écriture sur le port (débranché entre temps ... je suis vicieux), si j'arrête et ferme le MediaPlayer avant de quitter par "Close" dans ma routine d'écriture, mon appli se ferme sans laisser de traces, mais c'est la fenêtre qui passe en grisé et qui fait l'effet "champ de force" pendant 1s. Si je le fais en le fermant juste sans l'arrêter, je n'arrive plus à relancer l'exécutable. Si je quitte sans fermer le MediaPlayer, mon exécutable reste aléatoirement ouvert dans les processus ... Donc ce n'est pas la faute à Delphi, mais à Windows et au MediaPlayer, ou à une interaction de celui-ci avec les drivers de l'interface HID. Je comptais me passer de son ... jusqu'au moment où je me suis rendu compte qu'en cas d'erreur d'écriture, si je supprimais par "dispose" un pointeur créé après l'ouverture réussie de l'interface, je provoquais un magnifique plantage avec proposition d'envoyer le rapport d'erreur ! Donc voilà mon second interface USB (après FTDI) avec lequel une erreur d'accès (après débranchement ou non-branchement) met la zizanie dans les variables dynamiques.

Sans commentaire ! Vive le port parallèle (tant qu'il existe) !

[foetus]

Comme on te l'a dit, il faut temporiser : cela doit être un FreeLibrary ou petit frère qui prend du temps.
C'est un processus normal.

Il faut faire les tests dans le OnCreate ou le OnShow.

Et en cas de problèmes, dans le OnShow, afficher une pop-up d'attente de fermeture de l'application (avec un Application->Terminate à la fin)
Pour capturer la fin, Andnotor conseille le message WM_DEVICECHANGE.

Et si on veut faire super bien les choses , comme le conseille aussi exoseven, créer un timer ou un thread d'attente dans le OnShow pour temporiser l'affichage de l'application et mettre tout le code d'affichage/ tests/ gestion des problèmes/ ... dans une méthode qui sera appelée via un message personnel lancé par le timer ou le thread.

Et comme je l'ai dit, faire attention au OnActivate qui gère le focus.

[Invité]

grâce au composant HID Jedi. Il gère tous les accès, y compris la connexion et la déconnexion (et évite de mettre la dll). Au départ, un timer de 25ms est activé, il ferme la fiche sauf si auparavant il a été désactivé par la routine de détection ; 25ms suffisent pour détecter, et en cas d'absence de l'interface on voit juste un flash. Le "Unplug" dure 2s, mais si une écriture a lieu pendant ce laps de temps le test d'erreur ferme l'appli tout de suite. Et même le MediaPlayer fonctionne ... à condition de NE PAS LE FERMER EN QUITTANT (sinon "champ de forces"). Au passage je crois qu'il se ferme tout seul au moment de fermer la fiche ...
Voilà ... "La Force est avec moi ! "

[Invité]

sans l'usage du composabt HID, aussi bien la perte des pointeurs que les exe restés ouvert ou le plantage à la fermeture de MediaPlayer, à condition d'ajouter "Sender : TObject" dans la liste des paramètres de TOUTES les routines, y compris certaines non-événementielles où il ne sert à rien a priori.
Par contre les problèmes du "on(de)activate" et du Main.Close dans la routine "OnCreate" demeurent, il faut alors utiliser Halt(0) (qui apparemment ferme aussi sans laisser de traces).