Discussion :

[[DreaMs]]

Bonjour,

J'ai un petit programme Delphi que je lance sur mon pc et qui plante systématiquement. Je m'explique:
- Le programme fait des calculs et discute avec une base de données, une fois que je le lance il tourne environ 5 min.
- Sur mon pc de travail le processus plante au bout d'un moment (aléatoire à priori) et occupe 100% du cpu mais n'avance plus.
- Sur mon pc portable le programme se déroule en entier sans soucis.

Plus bizarre encore lorsque je force l'arrêt de mon programme une fois qu'il est planté ... c'est l'explorer.exe qui prend alors 100% du cpu !!! et cela uniquement sur mon pc de travail.
J'ai parfois l'erreur suivante :
"Erreur système, code : 1400 handle de fenêtre non valide"

Je travail en multiécran (j'apporte cette précision car certaines recherches sur internet m'ont apporté des possibles erreurs due à cela.

Si vous avez des idées je suis + que preneur !

Merci

[Rayek]

Peux tu faire voir ton code qui fait le calcul ?

[LadyWasky]

Ce serait bien aussi de connaitre les différences entre les 2 PC :
- taches de fond active (antivirus)
- puissance de calcul (micro-processeur, carte graphique)

ainsi qu'une description du plantage (écran bleu, ou "ce programme ne répond plus"-->utilisation indiquée de application.processmessage)

Remplis tu une liste quelque part (TStringList, TListView, TMemo, TStringGrid -->utilisation des méthodes BeginUpdate, EndUpdate peut être nécessaire)

etc...
Merci

[[DreaMs]]

il n'y a pas qu'un calcul le code est assez complexe et je ne peux pax vraiment le copier coller ici. il y a des calculs et bcp d'accès à une base de données (distante).

pour l'instant je ne l'ai testé que sur 2 pcs mais je vais le lancer sur d'autres pcs.

sur mon pc de bureau (Pentium IV 3Ghz + 1Go de RAM GeForce 5200) il plante (y compris si je le lance tout seul au lancement de Windows) et sachant que j'ai formaté une première fois qd j'ai eu ce problème. Donc mon install est propre.

Le plantage apparait sous la forme de ma fenêtre qui ne se rafraichit plus et par le fait que le processus prend 100% du cpu (en fait 50% car il y a l'hyperthreading). Lorsque je le fait CTR-F2 pour arrêter mon appli cela fonctionne mais c'est alors Explorer.exe qui prend 100% du cpu !!!

Mon portable est un Core2Duo 2Ghz + 2GoRam + ATI X1400. La le programme tourne sans soucis.

Je vais tester sur le poste de 2 collègues (dont un qui a 2 écrans également).

Sinon oui j'utilise de nombreux objets et également des StringList.

Merci pour votre aide

[LadyWasky]

Déjà, ce serait pas mal si, avant le remplissage de tes stringlist (rattachées ou nom à des composant graphiques : TMemo.Lines), tu écrive ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var MaListe:TStringList;
     Memo1:TMemo;
....
//avant le traitement long
MaListe.BeginUpdate;
Memo1.Lines.BeginUpdate;
...
//Traitement long
for i:=0 to 150000 do
   MaListe.Add('Une Ligne de Texte');
...
//après le traitement long
MaListe.EndUpdate;
Memo1.Lines.EndUpdate;

Celà accélèrera sensiblement les traitements.

De même, si tu parcours les champs d'une base de données et que tu as des contrôles DB-aware qui y sont reliés, ce ne serait pas un mal de désactiver l'affichage des données dans ces composants.

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
var MaTable:TTable;
...
//avant le traitement long
MaTable.DisableControls;
...
//Traitement long
MaTable.First;
while not Matable.eof do
begin
   Matable.FaireQuelqueChose(Lecture ou ecriture de donnees); //<--exemple fictif ;)
   MaTable.Next;
end;
...
//après le traitement long
MaTable.EnableControls;

Et sinon, laisse la main de temps en temps au système, en plaçant en fin de boucle dans ton traitement long, des

Code :

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

Application.ProcessMessages;

Celà évitera à Windows de se figer (dessin de la fenêtre et terminaison de processus) et te permettra de prendre la main sur ton programme pour l'arrêter (le message windows qui termine ton application lorsque tu tues son processus via le gestionnaire des tâches sera alors traité par ton programme)

Honnêtement, ça devrait améliorer sensiblement les choses.

[LadyWasky]

Sinon, les messages du type Handle de fenètre non valide, ça craint
Soit tu as créés beaucoup trop de contrôles fenétrés (TForm, TPanel, TLabel) et tu remplies la mémoire de windows chargée de gérer les handle de fenètre qui n'en peu plus.
Soit tu recrées une instance d'un contrôle fenétré déjà existant (TForm, TPanel, TLabel), sans avoir pris soin de détruire l'instance déjà existante.
Soit tu affecte accidentellement la propriété Handle d'un de tes contrôle fenétré (TForm, TPanel, TLabel); --> à éviter.
Soit tu utilise des composants tierce partie mal codés ou mal adaptés à ta version de delphi (ça m'est déjà arrivé). D'ailleurs, ça m'est déjà aussi arrivé avec un ensemble d'experts (cnPack), j'ai désinstallé et tout est rentré dans l'ordre.
Soit tu crés des instance de fenètre (handle de fenètres HWND) ou de resources graphiques (handle de dessin HDC avec la fonction windows GetDC) que tu ne libères jamais (ReleaseDC))

Les raisons peuvent être multiples