C'est à dire,
Dans un projet déja pas mal avancé, les instructions pour parser un fichier texte (ReWrite, CloseFile) génèrent une erreur d'entrée/sortie, alors que dans un projet vierge, elles marchent sans problème...    
 
Qu'est-ce qui dans un projet peut faire merder ce genre de commandes ?

[edtdd]--Message édité par ciler--[/edtdd]

fichier non fermé à un moment ?

NOn, c'est le seul moment dans l'appli ou j'ouvre/edite/ferme un fichier

C quoi commes les erreurs ?

C'est une erreur d'entrée sortie, mais j'ai plus le n° en tête...

 
Benh quand tu le vois, tu le note puis tu fais CTRL+F1 tu regardes I/O Error et tu verras ce que c'est... Mais sans le numéro, on sait rien, mais alors rien faire pour toi...  

J'ai les numéros, vous allez voir c'est fun
Je fais AssignFile puis
CloseFile -> Erreur 103 "fichier non ouvert"
ReWrite -> Erreur sans numéro
 
Mais...
Si j'utilise ces fonctions dans la procédure Click d'un bouton, ça marche sans erreur (jusque la, elles étaient dans une procédure à part et   qd j'appelais la procédure)

T'as un bug dans ton code....
T'appelle deja close dans un evenement ou un truc comme ça...... non ?

 
Ben non... et c'est bien le problème... J'ai rien qui se rattache à la fermeture d'un fichier (à part un fichier qui est ouvert/parsé/refermé par une dll, mais ça m'étonnerais que le pb vienne de là). De toute façon, je vais re-tester sur un projet vierge en mettant le traitement de fichier en procédure seule ou dans un bouton.

Et t'as pas des pb à l'ouverture ? (Tu fais la gestion des erreurs ?)

[edtdd]--Message édité par [SDF]Poire--[/edtdd]

tu peux mettre le code exaste, demoin depuis l'ouverture jusqu'a la fermeture
 
j'ai peux être une idée mais je veux voir le code avant

procedure TFormMain.MakeCommandLine();
var
   LSTFile: TextFile;
Begin
   LSTCount := LSTCount + 1; //LSTCount est une variable locale de TFormMain
   AssignFile(LSTFile, 'C:\test.txt');
   CloseFile(LSTFile); <- Et là, erreur 103
end;
 
Euh, si tu veut le code du projet in-extenso... J'ai peur qu'il fasse un peu 3 unités et pas mal de lignes...

[edtdd]--Message édité par ciler--[/edtdd]

Elle est où la gestion des erreurs ?
Pq tu l'ouvres pour le fermer tout de suite ?

Ben, si je fais ReWrite, ça merde aussi
J'ai pas fait de gestion d'erreur parce-que il devrait pas encore y avoir d'erreur à ce niveau...

Fais la tjs on sait jamais.....

T sur que ton fichier n'est pas déjà ouvert ?

Certain !

avant de pouvoir écrire dans ton fichier tu dois l'ouvrir avec reset (après assignfile)

Idem barre, erreur avec reset comme avec ReWrite...

Donne la valeure de LSTFile

Comment je fais ça ? LSTFile, c'est un nombre ? (Pour moi, c'est un TextFile, donc une référence à un fichier, mais peut-être que cette ref est un entier ?)

C un handle tu peux lire ça valeur (dans le pire des cas debugger->evaluer)

ciler a écrit a écrit :

Ca me dit po sa valeur.....

Ca voulait dire merci... POur la méthode de récupérage...
 
Sauf qu'aucune ne marche, impossible de savoir la valeur

pose un point d'arrêt sur la ligne où ça merde (clique gauche sur coté gauche de la fiche de code), F9, hop ! ça passe directement en debug au niveau du pt d'arrêt, puis laisse le curseur de ta souris sur la variable dont tu veux connaitre la valeur, si il te dit valeur inaccessible, tu fais F7 pour qu'il passe à la ligne suivante et pour qu'il évalue l'expression, si t'as pas de ligne suivante, fais-en une bidon ( i := 0, par exple)
et puis récupère qd même les erreurs à l'ouverture, ça poura t'aider à comprendre ce qu'il se passe.

pose un point d'arrêt sur la ligne où ça merde (clique gauche sur coté gauche de la fiche de code), F9, hop ! ça passe directement en debug au niveau du pt d'arrêt, puis laisse le curseur de ta souris sur la variable dont tu veux connaitre la valeur, si il te dit valeur inaccessible, tu fais F7 pour qu'il passe à la ligne suivante et pour qu'il évalue l'expression, si t'as pas de ligne suivante, fais-en une bidon ( i := 0, par exple)
et puis récupère qd même les erreurs à l'ouverture, ça poura t'aider à comprendre ce qu'il se passe.

pose un point d'arrêt sur la ligne où ça merde (clique gauche sur coté gauche de la fiche de code), F9, hop ! ça passe directement en debug au niveau du pt d'arrêt, puis laisse le curseur de ta souris sur la variable dont tu veux connaitre la valeur, si il te dit valeur inaccessible, tu fais F7 pour qu'il passe à la ligne suivante et pour qu'il évalue l'expression, si t'as pas de ligne suivante, fais-en une bidon ( i := 0, par exple)
et puis récupère qd même les erreurs à l'ouverture, ça poura t'aider à comprendre ce qu'il se passe.

Merci, mais comme je l'ai déja dit :

 
[SDF]Poire m'a déja expliqué comment faire mais ça ne marche pas, c'est tout !
 
Au fait, testé sur projet vierge, que les procédures d'I/O sur un fichier texte soient passées dans le code d'un bouton ou une procédure, elles fonctionnent.
Dans mon prjet, elles fonctionnent seulement dans un code de bouton Il doit y avoir un problème de déclaration...
 
PS : je suis pas exactement un newbie en prog... Donc l'art du debuggage, c'est les premières recherches que j'ai fait. Quand à de la gestion d'erreur, je refuse d'en faire parce-qu'a ce niveau de codage c'est pas admissible, il n'y a aucune opération à risque d'erreur dans mon programme.

J'ai trouvé la cause du problème... sans me l'expliquer pour autant...
 
Je résume tout :  
Dans un projet, les instructions d'entrée/sortie d'un fichier texte provoquent toutes une erreur (103 ou fichier non ouvert) sauf AssignFile si elles sont placées dans une procédure qui dépend directement d'unTForm. Par  contre pas d'erreur si elles sont dans le code Click d'un bouton par exemple.
Après plusieurs heures de début, j'ai finis par déterminer d'où vient le problème.  
Dans ma Form, j'ai un TFileListBox et un TDriveComboBox.  
Dans le code onChange du TDriveComboBox, j'ai la ligne

Eh bien si je met cette ligne en commentaire, les erreurs d'E/S disparaissent
 
A votre avis, quelle est la relation ?
 
Et une remarque en passant :
- Créez un projet vierge, mettez y un TDriveComboBox et dans le code onChange de celui-ci, mettez la ligne

Chez moi, si je change le disque dans le combo à l'exécution, le message apparait 2 fois    
Et chez vous, ça fait ça aussi ?

ces trucs genre DriveComboBox c'est de Win3.1 c'est pas recommandé de l'utiliser.
pour remplacer DriveComboBox/DirectoryListBox en Delphi 6 y a le ShellTreeView ou ShellComboBox.
et pour remplacer FileListBox y a le ShellListView
c'est plus joli et je pense que ça pose moins de problèmes.

 
Ben oui, mais dans mon cas, j'ai besoin de sélectionner un lecteur (DD ou CD), et pas le bureau ou la corbeille, alors comment je peut faire sans DriveComboBox ?
 
(a si, mettre une gestion d'erreur qui sort si bureau sélectionné...)

y a pas moyen de restreindre la sélection possible ?
 
edit: non apparemment pas

[edtdd]--Message édité par antp--[/edtdd]