Discussion :

[petitcoucou31]

Bonjour à tous,

j'ai déjà envoyé des posts sur un problème que j'ai pas toujours résolus, Un problème de plantage sporadique et en fonction de son utilisation, avec un "OutOffmemory".

Je suis peut être sur une voie et j'aimerai avoir votre avis avant de commencer une grosse modification de mon code !!.

je vais essayer d'être le plus clair possible. je suis sous delphi7 et XP, et m'excuse d'avance sur la longueur du post !

1° Le logiciel :

Il est basé sur une "form" maitresse, qui fait appel à des DLLs qui possèdent leur propre "form" et sont donc toutes autonomes, en fait ces DLLs sont des outils au programme principal.
En règle générale un seul outil est ouvert à la fois, et j'utilise la même structure de création de mes form dans chaque DLL.

2° les créations de mes forms

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
39
40
41
42
43
44
 
// si la fenêtre est visible, fonctionnement normal.
function ExConfigLogicielle:integer;stdcall;
begin
        result:=0;
        if assigned(FCongLog) then
        begin
             FCongLog.Release;
             FCongLog:=nil;
        end;
 
        FCongLog:=TFCongLog.create(application);
        try
             FCongLog.Showmodal;
        finally
             FCongLog.Release;
             FCongLog:=nil;
        end;
        result:=0;
end;
//-----------------------------------------------------------------------------
// si la fenêtre est invisible, appel de fonction sans décision d'utilisateur
function ExLitIndiceConfigLogicielle(index:integer):Pchar;stdcall;
begin
         result:='';
         if assigned(FCongLog) then
         begin
             FCongLog.Release;
             FCongLog:=nil;
         end;
 
         FCongLog:=TFCongLog.create(application);
         try
             Indice:=index;
             FCongLog.litConfig;
             FCongLog.LitOption;
             result:=pchar(EtatIndice);
             FCongLog.close;
         finally
             FCongLog.Release;
             FCongLog:=nil;
         end;
         result:=0;
end;

3° Ce qui m'a mis sur une voie

D'une part, certains clients m'ont dis que le plantage arrivait le plus souvent quand ils ouvraient rapidement des outils, comme si il fallait attendre qu'une fiche soit bien fermé et son processus terminé avant d'en ouvrir une autre !!.

D'autre part, j'ai une Dll qui possède la configuration et les options du logiciel, celle Dll est souvent utilisé en mode "form" non visible pour lire les options.
La fiche est créée et détruite à chaque lecture d'une option et peut parfois lire plusieurs options consécutivement, (c'est la fonction donnée ci-dessus ExLitIndiceConfigLogicielle(index:integer)). Et j'ai constaté que ce plantage arrivé aussi le plus souvent quand je lis des options consécutivement.

Pour Imager, supposons le code suivant qui peut illustrer la lecture de plusieurs options...ou je crée et détruit 20 fois la fiche qui se trouve dans la DLL ... et cela rapidement dirons nous..

Code :

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

1
2
3
4
5
6
 
Procedure Form1.Toto;
var i: integer;
begin
    for i:=1 to 20 do S:=ExLitIndiceConfigLogicielle(i);
end;

Voila j'espère avoir été clair et indiqué assez d'infos..

Donc à votre avis, ce codage est il correct ? peut il avoir une incidence sur mon problème de mémoire, dois je continuer dans cette voie.. en deux mot qu'en pensez vous ??
Toutes les idées ou critiques seront le bien venu et merci d'avance.

[Jipété]

Salut !

ou je crée et détruit 20 fois la fiche qui se trouve dans la DLL ... et cela rapidement dirons nous..

Bon, moi perso je trouve cela idiot, mais il y a peut-être une raison ?
Le problème, c'est qu'on sait que Windows perd des messages quand des choses se passent trop vite : par exemple un bricolo pour lire la position de la souris et l'ajouter dans un mémo, ben selon que tu bouges + ou - vite la souris, t'as - ou + de lignes dans le mémo...
À partir de ce comportement erratique, je dirais que tout est possible avec cet OS à deux balles.
C'est juste mon avis d'amateur, mais si ça peut faire avancer le schmilblik...

[petitcoucou31]

pourquoi comme çà ..

Au départ c'était juste une fonction qui donnait l'état d'une option au programme ou a une de ses DLLs ( style respecter la case dans le tri.. ) donc pas souvent sollicitée . Le temps passant les options on bien sur augmenter et ont a gardés cette fonction comme elle avait été codée.

Pourquoi aussi je lis pas directement le fichier "option" ,parce que c'est la fiche qui met en formes les options et me permet de les récupérer ..

donc avant de recoder tout cela , vos avis m'interresse !!

merci en tous cas pour ta réponse ..

[Jipété]

Pourquoi aussi je lis pas directement le fichier "option" ,parce que c'est la fiche qui met en formes les options et me permet de les récupérer ..

Ben tu pourrais lire tes options au lancement du prog et mettre les valeurs dans une liste (TStringList), et la fonction qui a besoin d'une valeur va la lire dans cette liste ?
Des fois, faut savoir tout recoder, car les rustines sur des rustines, moyen, quoi.

[petitcoucou31]

re ,

C'est en effet ce que j'ai envisagé aussi lire toutes mes options en une seule fois et cela pour chaque DLL qui doivent rester autonome. Mais çà ne règlera peut être que le problème de la lecture " options".
Ca ne me donne pas plus d'infos sur l'ouverture consécutive des DLLs qui donnent parfois le même défaut.

[Jipété]

Un problème à la fois !,

[Franck SORIANO]

Donc à votre avis, ce codage est il correct ? peut il avoir une incidence sur mon problème de mémoire, dois je continuer dans cette voie.. en deux mot qu'en pensez vous ??
Toutes les idées ou critiques seront le bien venu et merci d'avance.

A mon avis, le problème vient de tes appels à Release. Tu devrais faire des free à la place.

On utilise Release pour retarder la destruction d'une form dans le cas où le code qui la détruit serait appelé depuis un gestionnaire d'événement de la forme. Car dans ce cas, la suite de l'exécution des gestionnaires d'événements peut continuer à travailler sur la fiche elle même. Aussi, release dit à Delphi que la fiche doit être détruite, mais ne la détruit pas immédiatement, elle ne sera détruite que lorsque le code aura fini de traiter les messages windows.

Hors dans ton code, tu crées la fiche, tu fais un release pour la détruire, et tu réaffectes la fiche dans la foulée. Le tout avec une variable globale.
Il se peut qu'à un moment ton code se morde la queue et que ce ne soit pas la bonne instance qui est détruite (ou que le code du destructeur de l'instance précédente utilise la variable globale pour accéder à l'instance que tu as recrées juste derrière...(genre pour affecter la variable à nil)).

Regarde pour remplacer tes Release par des Free. Un Release après un ShowModal ça ne sert à rien. Lorsque ShowModal te rend la main tu es sûr que la fiche n'est plus en train de traiter des messages windows...
Release n'a de sens que si tu détruis la fiche dans l'un de ses gestionnaires d'événements.

[petitcoucou31]

merci Franck SORIANO.. je suis en train de modifier la lecture de mes options , mais je vais aussi suivre ton conseil..
je vous tiendrai au courant ..