Discussion :

[Teufel]

L' instruction Application->Terminate() n' a pas un effet immédiat.
Existe t il une instruction provoquant un arrêt immédiat ?
Environnement W2000 ou XP et CB5.

[Mac LAK]

ExitProcess, mais de toutes façons, aucune fonction n'aura un effet absolument immédiat... Et puis elle met combien de temps à se terminer, ton application ??
En plus, c'est dangereux, car des ressources et de la mémoire peuvent être perdues => instabilité de la machine si tu exagères.

Regarde sur MSDN, ExitProcess tout ce que fait la fonction, tu comprendras que ça ne peut pas être immédiat...

Essaie quand même de terminer ton application un peu plus proprement, ça sera mieux à tout point de vue... Libère les ressources, les fiches, la mémoire, les DLL, etc. au fur et à mesure que tu n'en as plus besoin, de manière à "soulager" la procédure de terminaison de l'application.

[Fbartolo]

Désolé de taper l'incrust, mais moi de temps en temps j'ai un programme qui se ferme mais qui garde un processus en cours.
L'application n'est plus visible dans le gestionnaire de tâche, mais un processus à son nom tourne toujour.

ensuite comme je regarde si le PGM n'est pas déja lancé... il se lance plus...

l'utilisateur quitte en fermant la fiche principale sur la croix.
est-ce suffisant ???? comprends pas.

des idées (ça peut pas venir du Mutex ?? ou d'un gif animé qui est sur la fiche ??)

[Mac LAK]

L'application n'est plus visible dans le gestionnaire de tâche, mais un processus à son nom tourne toujour.

Alors, ton processus est toujours actif, mais "planté" après la fermeture de la fiche principale : tu devrais tracer ton code au debugger, pour voir ce qu'il se passe après la fermeture... A priori, tu ne sors pas réellement du "Application->Run()", ce qui peut être causé par presque n'importe quoi... Attente de mutex/évènement avec timeout infini, interblocage lors de la fermeture des threads, etc, etc...

ensuite comme je regarde si le PGM n'est pas déja lancé... il se lance plus...

Ca peut effectivement être un mutex, dans ce cas : as-tu protégé ton application contre un double lancement de cette manière ?

l'utilisateur quitte en fermant la fiche principale sur la croix.
est-ce suffisant ???? comprends pas.

Normalement, oui. Cependant, il faut avoir pensé, dans le OnDestroy, à détruire ce que tu aurais pu initialiser manuellement dans le OnCreate...

des idées (ça peut pas venir du Mutex ?? ou d'un gif animé qui est sur la fiche ??)

GIF animé : si c'est un thread qui l'anime, oui. Si c'est un simple timer Windows (TTimer), alors non. Le mutex est également un coupable potentiel.

[Fbartolo]

Bonsoir, merci pour ces informations; ci joint le code de réalisation du test de fonctionnement.

L'application ne plante pa tout le temps,lorsqu'elle est fermée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    try
    {
     // Teste si l'appication est déja lancée Afin de ne pas lancer 2 fois
 
     HANDLE hMutex=CreateMutex (NULL,FALSE,"Application AutoMon");
    if (GetLastError() == ERROR_ALREADY_EXISTS)
        {
        if(hMutex!=NULL)
            CloseHandle(hMutex);
        AnsiString Title(Application->Title);
        Application->Title = "Automon";
        HANDLE hForm=FindWindow("TApplication",Title.c_str());
        if(hForm!=NULL)
            SetForegroundWindow(hForm);
        Application->Title=Title;
                                // Quitter le programme !
        return 0;
        }
        // ------------------------------------------------
 
        Application->Initialize();
        Application->CreateForm(__classid(TC3), &C3);
        Application->CreateForm(__classid(TConfigurationBox), &ConfigurationBox);
        Application->CreateForm(__classid(TBatchForm), &BatchForm);
        Application->CreateForm(__classid(TPasswordDlg), &PasswordDlg);
        Application->CreateForm(__classid(TDebugMode), &DebugMode);
        Application->CreateForm(__classid(TAboutBox), &AboutBox);
        Application->Run();
    }
    catch (Exception &exception)
    {
        Application->ShowException(&exception);
    }
    return 0;
}

[Gilles Louïse]

L' instruction Application->Terminate() n' a pas un effet immédiat.

Il faudrait nous dire où vous placez cette instruction. J'ai remarqué aussi qu'on ne peut pas la placer n'importe où, notamment pas à l'intérieur d'une boucle. Le mieux est de savoir revenir à la source c'est-à-dire à l'événement qui a créé l'action et d'utiliser cette instruction au premier niveau dans l'événement lui-même (premier niveau=pas dans une boucle mais en tant qu'instruction faisant partie de la suite). Si donc une boucle fait un test de sortie, il faut procéder par flag, la boucle positionne le flag et vous testez ce flag au premier niveau dans le gestionnaire d'événement. J'ai observé qu'en procédant ainsi ça marchait très bien.

À bientôt
Gilles

[Mac LAK]

Déjà, ton indentation de code est confusante : ton test en cas de multi-instance (mutex qui existe déjà) n'est pas clairement "détachée" de l'exécution normale, c'est une source d'erreur assez fréquente.

Ensuite, lorsque ton appli existe déjà, tu "planques" la nouvelle instance, et tu mets le focus sur l'ancienne. OK, très bien. Mais tu utilises "Application->Title" avant d'avoir initialisé ton instance (Application->Initialize()), et ça, c'est nettement moins bien : tu risques des problèmes.
Si tu veux le faire avant, tu devrais utiliser EnumWindows et comparer avec le PID de l'application courante (un exemple ici, fouille dans les liens présentés sur la page).
Par contre, je suis surpris que tu ne prennes pas le mutex sur ta première instance, et que tu ne fasses que tester son existence... Mais bon, si ça marche, pourquoi pas ?

Lorsque ton application est correctement terminée, n'oublie pas de relâcher le mutex (si nécessaire) et de fermer son handle, c'est plus propre.

Hormis ces points, qui sont "gênants" mais pas forcément critiques, je n'ai pas l'impression que c'est dans cette partie que se situe l'erreur, mais dans les gestionnaires OnClose / OnCloseQuery / OnDestroy de ta fiche principale.

[Teufel]

Merci à tous, et particulièrement à Gilles, le système du flag est beaucoup plus efficace.