SIGNIFICATION DES CODES D'ERREUR DE L'API WIN32 - UTILISATION D'UNE TLISTVIEW
cs_Jean_Jean
Messages postés
615
Date d'inscription
dimanche 13 août 2006
Statut
Membre
Dernière intervention
13 décembre 2018
-
12 oct. 2007 à 23:00
cs_Jean_Jean Messages postés 615 Date d'inscription dimanche 13 août 2006 Statut Membre Dernière intervention 13 décembre 2018 - 25 oct. 2007 à 19:25
cs_Jean_Jean Messages postés 615 Date d'inscription dimanche 13 août 2006 Statut Membre Dernière intervention 13 décembre 2018 - 25 oct. 2007 à 19:25
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44362-signification-des-codes-d-erreur-de-l-api-win32-utilisation-d-une-tlistview
https://codes-sources.commentcamarche.net/source/44362-signification-des-codes-d-erreur-de-l-api-win32-utilisation-d-une-tlistview
25 oct. 2007 à 19:25
Function FErrorAPIToStr(CodErrorAPI : Integer): String;
Begin
{ SysErrorMessage retourne parfois une chaîne vide }
if ArrStrErrorCodes[CodErrorAPI] = EmptyStr
then Result := '[non documenté]'
else Begin
{Des caractères retour chariot parasitent certaines chaînes }
Result := SysErrorMessage(CodErrorAPI);
{On ajoute la signification du message d'erreur dans la 3ème colonne }
Result := StringReplace(Result, #13#10, '', [rfReplaceAll]);
end;
end;
Je l'utilise en incluant l'unité dans le Uses du code que je veux surveiller.
Exemple :
if not RenameFile(FicDonnees, ChangeFileExt(FicDonnees,'.old')) then
begin
ER := GetLastError;
if MessageDlg(FicDonnees +' ne peut être sauvegardé en Bakup!'+#13#10+
'Erreur : '+IntToStr(ER)+' => '+FErrorAPIToStr(ER)
+#13#10+'Continuer ?',mtConfirmation, [mbYes, mbNo],0) = mrYes then
begin
... on continue
end;
end;
19 oct. 2007 à 16:08
Si c'est pas déplorable ça...
Moi aussi je note 10/10: faut bien motiver les troupes, et ce programme est super pratique.
A proposer aussi pour les autres langages, puisqu'il ne s'agit pas d'erreurs de Delphi.
17 oct. 2007 à 22:33
Je n'avais pas encore vu ce subtil changement de l'interface de CS qui consiste à devoir commenter quand on veut noter.
Finies les anciennes pratiques anonymes déplorables!
C'est bien.
Donc, je note(10) et pardon pour la vacuité de ce msg.
17 oct. 2007 à 21:53
Là-dessus, je n'ai aucun doute, mais il ne faut surtout pas que ça nous empêche de manger.
Salut, Cari, nos messages se sont croisés...
17 oct. 2007 à 21:47
Pour effectuer les tests, j'ai remplacé la procedure initiale par celle-ci :
procedure TForm1.ListErrors;
var
i: Integer;
S: string;
Compteur: Integer;
begin
Compteur := 0;
StatusBar1.SimpleText := '';
with ListView1.Items do
begin
Clear;
BeginUpdate;
for i := 0 to 20000 do // on prévoit large
begin
S := SysErrorMessage(i);
if S <> EmptyStr then
begin
S := StringReplace(S, #13#10, '', [rfReplaceAll]);
with Add do
begin
Caption := IntToStr(Compteur);
SubItems.Add(IntToStr(i));
SubItems.Add(S);
Inc(Compteur);
end;
end;
end;
EndUpdate;
NombreItems := Compteur;
end;
end;
Voici les résultats que j'obtiens :
Delphi 4 pro - Win98 : 658
(doublons : 14)
Delphi 6 entreprise - Win98 : 658
(doublons : 14)
Delphi 7 entreprise - Win98 : 658
(doublons : 14)
Delphi 4 pro - XP : 2661
(doublons : 70)
Delphi 6 entreprise - XP : 2661
(doublons : 70)
Delphi 7 entreprise - XP : 3008
(doublons : 95)
Delphi 4 pro - Vista : 3263
(doublons : 71)
Delphi 6 entreprise - Vista : 3263
(doublons : 71)
Delphi 7 entreprise - Vista : 3626
(doublons : 97)
Les doublons relevés sont des messages d'erreurs identiques correspondant à des codes d'erreur différents (j'ai testé ultérieurement).
Voilà, maintenant il appartient à chacun de personnaliser s'il le désire en fonction de ses outils et de son système d'exploitation, le système de la ListView devenant alors caduque.
Bonne prog' :p
17 oct. 2007 à 21:47
Le doute existentiel ne doit pas reléguer la nécessité de se sustenter, hein, Japee? ;)
17 oct. 2007 à 20:59
Quand je serai dans le doute existentiel (genre dois-je m'acharner à continuer d'essayer de progresser avec Delphi), je reviendrai sur cette page où je puiserai une force nouvelle :-)
Zouriteman, bien vu :
Le nombre de messages d'erreur varie considérablement d'une version à l'autre de Delphi et de Windows.
D'ailleurs si tu avais élargi un peu ta boucle, tu en aurais trouvé d'autres (Delphi4_pro et XP : 2661)... :p
Je vais néanmoins en rester là, pour plusieurs raisons :
- les messages ramenés par SysErrorMessage ne semblent pas tous correspondre à un message d'erreur (regarde bien la liste générée),
- ceux que j'utilise sont des constantes déclarées dans Windows.pas de Delphi4 pro et sont donc utilisables avec toute version ultérieure et à partir de Win9x,
- ils me semblent suffisants pour la plupart des erreurs courantes et même beaucoup plus,
- pour résumer, compte tenu de la disparité des versions de Windows encore largement en service (9x, 2000, XP, Vista), il vaut mieux se limiter à une liste d'erreurs reconnue par tous les systèmes.
De plus, en récupérant ces messages dans une boucle, la constante n'est pas retournée, donc la première colonne de ma TListView ne sert plus à grand chose, et comme on peut éventuellement se passer de la troisième, ma ListView devient inutile, et tout mon didactitiel sur le tri est perdu par la même occasion. C'est pas ça que tu veux, dis ? (lol)
Bon, je fais un break et je reviens pour quelques explications supplémentaires.
A plus.
15 oct. 2007 à 19:03
===========
{ On récupère sa signification avec la fonction SysErrorMessage }
// Ajout G.CHABANT 15/10/2007
J := ArrErrorCodes[i] ;
if (J >= 0) and (J <= 9999) then begin
TERR[J] := 1 ;
end ;
//......
S := SysErrorMessage(J);
{ SysErrorMessage retourne parfois une chaîne vide }
===========
15 oct. 2007 à 18:46
J'en ai trouvé 1734 supplémentaires ; voci mes modifs ( compilé avec DELPHI5-PRO sous WinXP)
===== (dans TForm1 )
public
{ Déclarations publiques }
TERR : array[0..9999] of byte ; // Ajout G.CHABANT 15/10/2007
end;
===== (début de ListErrors )
procedure TForm1.ListErrors;
var
I , J , XDIF : Integer;
S: string;
begin
// Ajout G.CHABANT 15/10/2007
for I := 0 to 9999 do begin
TERR[I] := 0 ;
end ;
//.....
========
======== (fin de ListErrors )
// Ajout G.CHABANT 15/10/2007
XDIF := 0 ;
for J := 0 to 9999 do begin
if TERR[J] = 0 then begin
S := EmptyStr ; //**** Attention, la Chaine S n'est peut-etre pas ré-initialiséee
S := SysErrorMessage(J);
if S <> EmptyStr then begin
inc(XDIF) ;
with Add do begin
Caption := 'X' + IntToStr(XDIF) ;
SubItems.Add(IntToStr(J));
S := StringReplace(S, #13#10, '', [rfReplaceAll]);
SubItems.Add(S);
end;
end ;
end ;
end ;
if XDIF > 0 then begin
ShowMessage('Nombre de SysError non recensés = ' + IntToStr(XDIF) ) ;
end ;
//.....
EndUpdate;
end;
end;
========
15 oct. 2007 à 18:12
Toutefois, quelques questions
a) Il y a des trous dans la numérotation ( dernier code 6118 ) , par exemple au début 35 et 37 ; cela signifie t il que ces codes n'existent pas , ou que "JAPEE" les a oubliés ?
b) Question subsidiaire : Y a t il de nouveaux codes qui apparaissent avec les versions récentes de WINDOWS ( de Win95 vers Win98 puis WinXP puis Vista , ou des versions spécifiques : WinNT , Win2000 SERVER , Win 64 bits) ?
c) les codes désignés "non documentés" : qu'en est-il en réalité ?
.......
15 oct. 2007 à 11:08
Intéressant aussi est le traitement de la ListView qui ouvre d'autres horizons.
beau travail Japee.
14 oct. 2007 à 00:34
Elégant et concis.
Tout Japee, quoi...
Merci.
13 oct. 2007 à 14:45
Il manque plus que des conseils pour avoir la solution à l'erreur !!! ^^
12 oct. 2007 à 23:00
La simplicité de tes codes sont un régal.
C'est un source qui est utile pour les débug et mises au point!
Et SysErrorMessage n'utilise pas les ListView, alors t'a eu 1 bonne idée.
Bien à toi