J'ai un truc bizarre, que je n'arrive pas à
cerner, ma routine d'erreur semble ne pas
fonctionner, car, quand je tente d'ouvrir un
fichier inexistant, au lieu de débrancher à
l'adresse indiquée en cas d'erreur, il me sort une
erreur système "Fichier inexistant", et pourtant
je fais toujours ainsi, et ça marche ? Voici:
p01k = FreeFile
On Error GoTo erreur1
Open "mpprix.txt" For Input As p01k '
<<<---ERREUR ???
Line Input #p01k, trans
Close p01k
' ...
GoTo fin1
'
erreur1:
On Error Resume Next
Close p01k
p01k = FreeFile
Open "mpprix.txt" For Output As p01k
'...
--
Merci beaucoup, au revoir et à bientôt :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
Ah, ben non alors, je viens de tenter, juste le code, ça marche, il doit y avoir un concours de circonstances...
Sub Form_Activate() Dim p01k As Long Dim trans As String ChDrive App.Path ChDir App.Path p01k = FreeFile On Error GoTo erreur1 Open "mpprix.txt" For Input As p01k Line Input #p01k, trans Close p01k GoTo fin erreur1: MsgBox Err On Error Resume Next Close p01k fin: MsgBox "ok" Unload Form1 End End Sub
-- Merci beaucoup, au revoir et à bientôt :o) ------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | LE TROLL a utilisé son clavier pour écrire : | > Ah bon ??? Tu as fait un test ??? | > | > | | Oui évidemment. | |
Ah, ben non alors, je viens de tenter,
juste le code, ça marche, il doit y avoir un
concours de circonstances...
Sub Form_Activate()
Dim p01k As Long
Dim trans As String
ChDrive App.Path
ChDir App.Path
p01k = FreeFile
On Error GoTo erreur1
Open "mpprix.txt" For Input As p01k
Line Input #p01k, trans
Close p01k
GoTo fin
erreur1:
MsgBox Err
On Error Resume Next
Close p01k
fin:
MsgBox "ok"
Unload Form1
End
End Sub
--
Merci beaucoup, au revoir et à bientôt :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"tking" <thing@w.e> a écrit dans le message de
news: mn.eac77d7b04431f01.68335@w.e...
| LE TROLL a utilisé son clavier pour écrire :
| > Ah bon ??? Tu as fait un test ???
| >
| >
|
| Oui évidemment.
|
|
Ah, ben non alors, je viens de tenter, juste le code, ça marche, il doit y avoir un concours de circonstances...
Sub Form_Activate() Dim p01k As Long Dim trans As String ChDrive App.Path ChDir App.Path p01k = FreeFile On Error GoTo erreur1 Open "mpprix.txt" For Input As p01k Line Input #p01k, trans Close p01k GoTo fin erreur1: MsgBox Err On Error Resume Next Close p01k fin: MsgBox "ok" Unload Form1 End End Sub
-- Merci beaucoup, au revoir et à bientôt :o) ------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | LE TROLL a utilisé son clavier pour écrire : | > Ah bon ??? Tu as fait un test ??? | > | > | | Oui évidemment. | |
tking
LE TROLL avait soumis l'idée :
Ah, ben non alors, je viens de tenter, juste le code, ça marche, il doit y avoir un concours de circonstances...
(snip code)
J'ai plus simple, une form un bouton command1
' Essai avec mpprix.txt
Private Sub Command1_Click() On Error Resume Next Open "mpprix.txt" For Input As #1 MsgBox Err.Description End Sub
== resultat, aucune erreur! =
Autre essai, avec mx.txt par exemple
Private Sub Command1_Click() On Error Resume Next Open "mx.txt" For Input As #1 MsgBox Err.Description End Sub
== resultat, fichier introuvable !
Y'a un truc qui m'échappe .
LE TROLL avait soumis l'idée :
Ah, ben non alors, je viens de tenter,
juste le code, ça marche, il doit y avoir un
concours de circonstances...
(snip code)
J'ai plus simple, une form un bouton command1
' Essai avec mpprix.txt
Private Sub Command1_Click()
On Error Resume Next
Open "mpprix.txt" For Input As #1
MsgBox Err.Description
End Sub
== resultat, aucune erreur! =
Autre essai, avec mx.txt par exemple
Private Sub Command1_Click()
On Error Resume Next
Open "mx.txt" For Input As #1
MsgBox Err.Description
End Sub
Ah, ben non alors, je viens de tenter, juste le code, ça marche, il doit y avoir un concours de circonstances...
(snip code)
J'ai plus simple, une form un bouton command1
' Essai avec mpprix.txt
Private Sub Command1_Click() On Error Resume Next Open "mpprix.txt" For Input As #1 MsgBox Err.Description End Sub
== resultat, aucune erreur! =
Autre essai, avec mx.txt par exemple
Private Sub Command1_Click() On Error Resume Next Open "mx.txt" For Input As #1 MsgBox Err.Description End Sub
== resultat, fichier introuvable !
Y'a un truc qui m'échappe .
LE TROLL
Heu, c'est normal que tu n'aies pas d'erreur a "on error resume next", ça remet à 0, on peut faire ça, mais après, aussi, on va partir sur des suppositions fausses, s'il y avait une erreur, on ne peut pas faire ça en fait, car le but est de tester l'existence, voire de le lire; donc, si l'erreur est à 0, on va présumer au moins qu'il est créé mais vide, alors qu'il n'est pas créé... et au prochain accès, ça plante, là, sans trop comprendre pourquoi, faudra remonter le code... En plus, je ne sais même pas si dans ce cas, le pointeur est libéré, vu qu'il y a une erreur ignorée (resume next), si on réutilise le pointeur, peut être qu'il va dire: "fichier déjà ouvert"... Car, certes, il ignore l'erreur, mais je ne sais pas où il débranche, sans doute juste après l'erreur, soit après l'open, n'allant pas jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y ait une erreur, puisqu'il n'y a pas de fichier créé préalablement... Le "#"1... est-ce que sa dispense du FreeFile ? Car, sinon, le pointeur n'est pas affecté ?
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | LE TROLL avait soumis l'idée : | > Ah, ben non alors, je viens de tenter, | > juste le code, ça marche, il doit y avoir un | > concours de circonstances... | | (snip code) | | | | J'ai plus simple, une form un bouton command1 | | | | ' Essai avec mpprix.txt | | Private Sub Command1_Click() | On Error Resume Next | Open "mpprix.txt" For Input As #1 | MsgBox Err.Description | End Sub | | == resultat, aucune erreur! = | | | | | Autre essai, avec mx.txt par exemple | | Private Sub Command1_Click() | On Error Resume Next | Open "mx.txt" For Input As #1 | MsgBox Err.Description | End Sub | | | == resultat, fichier introuvable ! | | | Y'a un truc qui m'échappe . | |
Heu, c'est normal que tu n'aies pas
d'erreur a "on error resume next", ça remet à 0,
on peut faire ça, mais après, aussi, on va partir
sur des suppositions fausses, s'il y avait une
erreur, on ne peut pas faire ça en fait, car le
but est de tester l'existence, voire de le lire;
donc, si l'erreur est à 0, on va présumer au moins
qu'il est créé mais vide, alors qu'il n'est pas
créé... et au prochain accès, ça plante, là, sans
trop comprendre pourquoi, faudra remonter le
code...
En plus, je ne sais même pas si dans ce cas, le
pointeur est libéré, vu qu'il y a une erreur
ignorée (resume next), si on réutilise le
pointeur, peut être qu'il va dire: "fichier déjà
ouvert"... Car, certes, il ignore l'erreur, mais
je ne sais pas où il débranche, sans doute juste
après l'erreur, soit après l'open, n'allant pas
jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y
ait une erreur, puisqu'il n'y a pas de fichier
créé préalablement... Le "#"1... est-ce que sa
dispense du FreeFile ? Car, sinon, le pointeur
n'est pas affecté ?
--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"tking" <thing@w.e> a écrit dans le message de
news: mn.ec707d7b7188acab.68335@w.e...
| LE TROLL avait soumis l'idée :
| > Ah, ben non alors, je viens de tenter,
| > juste le code, ça marche, il doit y avoir un
| > concours de circonstances...
|
| (snip code)
|
|
|
| J'ai plus simple, une form un bouton command1
|
|
|
| ' Essai avec mpprix.txt
|
| Private Sub Command1_Click()
| On Error Resume Next
| Open "mpprix.txt" For Input As #1
| MsgBox Err.Description
| End Sub
|
| == resultat, aucune erreur! = |
|
|
|
| Autre essai, avec mx.txt par exemple
|
| Private Sub Command1_Click()
| On Error Resume Next
| Open "mx.txt" For Input As #1
| MsgBox Err.Description
| End Sub
|
|
| == resultat, fichier introuvable !
|
|
| Y'a un truc qui m'échappe .
|
|
Heu, c'est normal que tu n'aies pas d'erreur a "on error resume next", ça remet à 0, on peut faire ça, mais après, aussi, on va partir sur des suppositions fausses, s'il y avait une erreur, on ne peut pas faire ça en fait, car le but est de tester l'existence, voire de le lire; donc, si l'erreur est à 0, on va présumer au moins qu'il est créé mais vide, alors qu'il n'est pas créé... et au prochain accès, ça plante, là, sans trop comprendre pourquoi, faudra remonter le code... En plus, je ne sais même pas si dans ce cas, le pointeur est libéré, vu qu'il y a une erreur ignorée (resume next), si on réutilise le pointeur, peut être qu'il va dire: "fichier déjà ouvert"... Car, certes, il ignore l'erreur, mais je ne sais pas où il débranche, sans doute juste après l'erreur, soit après l'open, n'allant pas jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y ait une erreur, puisqu'il n'y a pas de fichier créé préalablement... Le "#"1... est-ce que sa dispense du FreeFile ? Car, sinon, le pointeur n'est pas affecté ?
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | LE TROLL avait soumis l'idée : | > Ah, ben non alors, je viens de tenter, | > juste le code, ça marche, il doit y avoir un | > concours de circonstances... | | (snip code) | | | | J'ai plus simple, une form un bouton command1 | | | | ' Essai avec mpprix.txt | | Private Sub Command1_Click() | On Error Resume Next | Open "mpprix.txt" For Input As #1 | MsgBox Err.Description | End Sub | | == resultat, aucune erreur! = | | | | | Autre essai, avec mx.txt par exemple | | Private Sub Command1_Click() | On Error Resume Next | Open "mx.txt" For Input As #1 | MsgBox Err.Description | End Sub | | | == resultat, fichier introuvable ! | | | Y'a un truc qui m'échappe . | |
tking
LE TROLL avait soumis l'idée :
Heu, c'est normal que tu n'aies pas d'erreur a "on error resume next", ça remet à 0, on peut faire ça, mais après, aussi, on va partir sur des suppositions fausses, s'il y avait une erreur, on ne peut pas faire ça en fait, car le but est de tester l'existence, voire de le lire; donc, si l'erreur est à 0, on va présumer au moins qu'il est créé mais vide, alors qu'il n'est pas créé... et au prochain accès, ça plante, là, sans trop comprendre pourquoi, faudra remonter le code...
Non, j'arrête et je relance le programme.
En plus, je ne sais même pas si dans ce cas, le pointeur est libéré, vu qu'il y a une erreur ignorée (resume next), si on réutilise le pointeur, peut être qu'il va dire: "fichier déjà ouvert"... Car, certes, il ignore l'erreur, mais je ne sais pas où il débranche, sans doute juste après l'erreur, soit après l'open, n'allant pas jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y ait une erreur, puisqu'il n'y a pas de fichier créé préalablement... Le "#"1... est-ce que sa dispense du FreeFile ? Car, sinon, le pointeur n'est pas affecté ?
non non, y'a bien une c***** avec le nom du fichier
LE TROLL avait soumis l'idée :
Heu, c'est normal que tu n'aies pas
d'erreur a "on error resume next", ça remet à 0,
on peut faire ça, mais après, aussi, on va partir
sur des suppositions fausses, s'il y avait une
erreur, on ne peut pas faire ça en fait, car le
but est de tester l'existence, voire de le lire;
donc, si l'erreur est à 0, on va présumer au moins
qu'il est créé mais vide, alors qu'il n'est pas
créé... et au prochain accès, ça plante, là, sans
trop comprendre pourquoi, faudra remonter le
code...
Non, j'arrête et je relance le programme.
En plus, je ne sais même pas si dans ce cas, le
pointeur est libéré, vu qu'il y a une erreur
ignorée (resume next), si on réutilise le
pointeur, peut être qu'il va dire: "fichier déjà
ouvert"... Car, certes, il ignore l'erreur, mais
je ne sais pas où il débranche, sans doute juste
après l'erreur, soit après l'open, n'allant pas
jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y
ait une erreur, puisqu'il n'y a pas de fichier
créé préalablement... Le "#"1... est-ce que sa
dispense du FreeFile ? Car, sinon, le pointeur
n'est pas affecté ?
non non, y'a bien une c***** avec le nom du fichier
Heu, c'est normal que tu n'aies pas d'erreur a "on error resume next", ça remet à 0, on peut faire ça, mais après, aussi, on va partir sur des suppositions fausses, s'il y avait une erreur, on ne peut pas faire ça en fait, car le but est de tester l'existence, voire de le lire; donc, si l'erreur est à 0, on va présumer au moins qu'il est créé mais vide, alors qu'il n'est pas créé... et au prochain accès, ça plante, là, sans trop comprendre pourquoi, faudra remonter le code...
Non, j'arrête et je relance le programme.
En plus, je ne sais même pas si dans ce cas, le pointeur est libéré, vu qu'il y a une erreur ignorée (resume next), si on réutilise le pointeur, peut être qu'il va dire: "fichier déjà ouvert"... Car, certes, il ignore l'erreur, mais je ne sais pas où il débranche, sans doute juste après l'erreur, soit après l'open, n'allant pas jusqu'au "close" ?
---------------
Dans ton second exemple, c'est normal qu'il y ait une erreur, puisqu'il n'y a pas de fichier créé préalablement... Le "#"1... est-ce que sa dispense du FreeFile ? Car, sinon, le pointeur n'est pas affecté ?
non non, y'a bien une c***** avec le nom du fichier
Gloops
Bonjour,
Je n'avais pas pensé à un problème de syntaxe, mais juste à un é diteur que tu aurais oublié de fermer après avoir jeté un coup d'il dan s le fichier.
Apparemment ça ne devait pas être ça, car tu aurais eu le temps de faire d'autres tentatives depuis, probablement en redémarrant au moins une fo is.
Je suppose que tu as bien vérifié dans l'explorateur la présence du fichier.
_______________________________________ LE TROLL a écrit, le 29/11/2007 04:15 :
Bonjour,
Merci, non, je crois que le "#" n'est obligatoire qu'à l'intérieur, pour l'input_line ou le print... C'est vrai que VB le met souvent en démo, mais pour les anglais ça veut dire "mettre un numéro, une valeur"...
Pour le pointeur pas bien refermé, en fait, les pointeur je les assigne très méticuleusement, ils portent toujours le nom de leur form p01, ... p09, puis une lettre a, b (p01a, p01b), dont je ne les réutilise pas, justement pour ne pas faire de salade, qui parfois arrive...
En fait, ce qui se passe, c'est que mon fichier n'est justement pas créé, puisque je tente une lecture sur un fichier peut être inexistant (à la première création)... C'est la façon de savoir s'il existe de facto. Mais normalement il devrait avec "on error goto", débrancher à l'erreur, ce qu'il ne fait pas, là est le problème... En fait, c'est la gestion d'erreur qui ne marche pas!
J'ai dû provoquer quelque chose de louche en codant, quelque chose qui perturbe, mais je ne sais pas quoi, le path est bon aussi, il est défini dans la même procédure...
J'avais:
on error goto open...input -------
Ben là j'ai bétonné:
open Append close on error goto open input EOF() = true...goto
Là, en force, ça marche, mais bon...
Bonjour,
Je n'avais pas pensé à un problème de syntaxe, mais juste à un é diteur
que tu aurais oublié de fermer après avoir jeté un coup d'il dan s le
fichier.
Apparemment ça ne devait pas être ça, car tu aurais eu le temps de faire
d'autres tentatives depuis, probablement en redémarrant au moins une fo is.
Je suppose que tu as bien vérifié dans l'explorateur la présence du fichier.
_______________________________________
LE TROLL a écrit, le 29/11/2007 04:15 :
Bonjour,
Merci, non, je crois que le "#" n'est
obligatoire qu'à l'intérieur, pour l'input_line ou
le print... C'est vrai que VB le met souvent en
démo, mais pour les anglais ça veut dire "mettre
un numéro, une valeur"...
Pour le pointeur pas bien refermé, en fait,
les pointeur je les assigne très méticuleusement,
ils portent toujours le nom de leur form p01, ...
p09, puis une lettre a, b (p01a, p01b), dont je ne
les réutilise pas, justement pour ne pas faire de
salade, qui parfois arrive...
En fait, ce qui se passe, c'est que mon
fichier n'est justement pas créé, puisque je tente
une lecture sur un fichier peut être inexistant (à
la première création)... C'est la façon de savoir
s'il existe de facto. Mais normalement il devrait
avec "on error goto", débrancher à l'erreur, ce
qu'il ne fait pas, là est le problème... En fait,
c'est la gestion d'erreur qui ne marche pas!
J'ai dû provoquer quelque chose de louche en
codant, quelque chose qui perturbe, mais je ne
sais pas quoi, le path est bon aussi, il est
défini dans la même procédure...
J'avais:
on error goto
open...input
-------
Ben là j'ai bétonné:
open Append
close
on error goto
open input
EOF() = true...goto
Je n'avais pas pensé à un problème de syntaxe, mais juste à un é diteur que tu aurais oublié de fermer après avoir jeté un coup d'il dan s le fichier.
Apparemment ça ne devait pas être ça, car tu aurais eu le temps de faire d'autres tentatives depuis, probablement en redémarrant au moins une fo is.
Je suppose que tu as bien vérifié dans l'explorateur la présence du fichier.
_______________________________________ LE TROLL a écrit, le 29/11/2007 04:15 :
Bonjour,
Merci, non, je crois que le "#" n'est obligatoire qu'à l'intérieur, pour l'input_line ou le print... C'est vrai que VB le met souvent en démo, mais pour les anglais ça veut dire "mettre un numéro, une valeur"...
Pour le pointeur pas bien refermé, en fait, les pointeur je les assigne très méticuleusement, ils portent toujours le nom de leur form p01, ... p09, puis une lettre a, b (p01a, p01b), dont je ne les réutilise pas, justement pour ne pas faire de salade, qui parfois arrive...
En fait, ce qui se passe, c'est que mon fichier n'est justement pas créé, puisque je tente une lecture sur un fichier peut être inexistant (à la première création)... C'est la façon de savoir s'il existe de facto. Mais normalement il devrait avec "on error goto", débrancher à l'erreur, ce qu'il ne fait pas, là est le problème... En fait, c'est la gestion d'erreur qui ne marche pas!
J'ai dû provoquer quelque chose de louche en codant, quelque chose qui perturbe, mais je ne sais pas quoi, le path est bon aussi, il est défini dans la même procédure...
J'avais:
on error goto open...input -------
Ben là j'ai bétonné:
open Append close on error goto open input EOF() = true...goto
Là, en force, ça marche, mais bon...
Gloops
tking a écrit, le 29/11/2007 18:56 :
== resultat, fichier introuvable !
Effectivement, c'est bizarre.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux fois de l'ouvrir, sans le refermer entre deux.
tking a écrit, le 29/11/2007 18:56 :
== resultat, fichier introuvable !
Effectivement, c'est bizarre.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux
fois de l'ouvrir, sans le refermer entre deux.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux fois de l'ouvrir, sans le refermer entre deux.
Mais non, ces deux exemples sont testés après arrêt du programme et modif du code et pas successivement.
Personne n'a d'explication ?
tking
tking a écrit :
Gloops avait soumis l'idée :
tking a écrit, le 29/11/2007 18:56 :
== resultat, fichier introuvable !
Effectivement, c'est bizarre.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux fois de l'ouvrir, sans le refermer entre deux.
Mais non, ces deux exemples sont testés après arrêt du programme et modif du code et pas successivement.
Personne n'a d'explication ?
Bon j'ai trouvé... la honte pour moi :( Le fichier "mpprix.txt" est par défaut dans le répertoire de visual basic. Et en l'absence du chemin dans la requête, c'est app.path qui est utilisé.
TROLL, t'as réussi ton coup.
tking a écrit :
Gloops avait soumis l'idée :
tking a écrit, le 29/11/2007 18:56 :
== resultat, fichier introuvable !
Effectivement, c'est bizarre.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux
fois de l'ouvrir, sans le refermer entre deux.
Mais non, ces deux exemples sont testés après arrêt du programme et modif du
code et pas successivement.
Personne n'a d'explication ?
Bon j'ai trouvé... la honte pour moi :( Le fichier "mpprix.txt" est par
défaut dans le répertoire de visual basic. Et en l'absence du chemin
dans la requête, c'est app.path qui est utilisé.
En revanche, pas d'erreur, je n'aurais pas compris non plus.
Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux fois de l'ouvrir, sans le refermer entre deux.
Mais non, ces deux exemples sont testés après arrêt du programme et modif du code et pas successivement.
Personne n'a d'explication ?
Bon j'ai trouvé... la honte pour moi :( Le fichier "mpprix.txt" est par défaut dans le répertoire de visual basic. Et en l'absence du chemin dans la requête, c'est app.path qui est utilisé.
TROLL, t'as réussi ton coup.
LE TROLL
Ah non, App.path mets implicitement le chemin dans le programme qui le génère, même répertoire, alors, en admettant qu'il y ait un autre fichier de ce nom, ailleurs, ça ne lui interdirait pas de fonctionner...
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | tking a écrit : | > Gloops avait soumis l'idée : | >> tking a écrit, le 29/11/2007 18:56 : | >>> == resultat, fichier introuvable ! | >> | >> | >> Effectivement, c'est bizarre. | >> | >> En revanche, pas d'erreur, je n'aurais pas compris non plus. | >> | >> Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux | >> fois de l'ouvrir, sans le refermer entre deux. | > | > Mais non, ces deux exemples sont testés après arrêt du programme et modif du | > code et pas successivement. | > | > Personne n'a d'explication ? | | Bon j'ai trouvé... la honte pour moi :( Le fichier "mpprix.txt" est par | défaut dans le répertoire de visual basic. Et en l'absence du chemin | dans la requête, c'est app.path qui est utilisé. | | TROLL, t'as réussi ton coup. | |
Ah non, App.path mets implicitement le chemin
dans le programme qui le génère, même répertoire,
alors, en admettant qu'il y ait un autre fichier
de ce nom, ailleurs, ça ne lui interdirait pas de
fonctionner...
--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"tking" <thing@w.e> a écrit dans le message de
news: mn.f1cb7d7bd0e4d86e.68335@w.e...
| tking a écrit :
| > Gloops avait soumis l'idée :
| >> tking a écrit, le 29/11/2007 18:56 :
| >>> == resultat, fichier introuvable !
| >>
| >>
| >> Effectivement, c'est bizarre.
| >>
| >> En revanche, pas d'erreur, je n'aurais pas
compris non plus.
| >>
| >> Je me serais plutôt attendu à fichier
verrouillé, puisque tu tentes deux
| >> fois de l'ouvrir, sans le refermer entre
deux.
| >
| > Mais non, ces deux exemples sont testés après
arrêt du programme et modif du
| > code et pas successivement.
| >
| > Personne n'a d'explication ?
|
| Bon j'ai trouvé... la honte pour moi :( Le
fichier "mpprix.txt" est par
| défaut dans le répertoire de visual basic. Et en
l'absence du chemin
| dans la requête, c'est app.path qui est utilisé.
|
| TROLL, t'as réussi ton coup.
|
|
Ah non, App.path mets implicitement le chemin dans le programme qui le génère, même répertoire, alors, en admettant qu'il y ait un autre fichier de ce nom, ailleurs, ça ne lui interdirait pas de fonctionner...
-- Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "tking" a écrit dans le message de news: | tking a écrit : | > Gloops avait soumis l'idée : | >> tking a écrit, le 29/11/2007 18:56 : | >>> == resultat, fichier introuvable ! | >> | >> | >> Effectivement, c'est bizarre. | >> | >> En revanche, pas d'erreur, je n'aurais pas compris non plus. | >> | >> Je me serais plutôt attendu à fichier verrouillé, puisque tu tentes deux | >> fois de l'ouvrir, sans le refermer entre deux. | > | > Mais non, ces deux exemples sont testés après arrêt du programme et modif du | > code et pas successivement. | > | > Personne n'a d'explication ? | | Bon j'ai trouvé... la honte pour moi :( Le fichier "mpprix.txt" est par | défaut dans le répertoire de visual basic. Et en l'absence du chemin | dans la requête, c'est app.path qui est utilisé. | | TROLL, t'as réussi ton coup. | |
tking
LE TROLL avait soumis l'idée :
Ah non, App.path mets implicitement le chemin dans le programme qui le génère, même répertoire, alors, en admettant qu'il y ait un autre fichier de ce nom, ailleurs, ça ne lui interdirait pas de fonctionner...
Si tu ne mets pas app.path le chemin courant est le chemin d'exécution du programme.
Donc open "toto.txt" indique que le fichier est dans le dossier d'exécution du programme.
LE TROLL avait soumis l'idée :
Ah non, App.path mets implicitement le chemin
dans le programme qui le génère, même répertoire,
alors, en admettant qu'il y ait un autre fichier
de ce nom, ailleurs, ça ne lui interdirait pas de
fonctionner...
Si tu ne mets pas app.path le chemin courant est le chemin d'exécution
du programme.
Donc open "toto.txt" indique que le fichier est dans le dossier
d'exécution du programme.
Ah non, App.path mets implicitement le chemin dans le programme qui le génère, même répertoire, alors, en admettant qu'il y ait un autre fichier de ce nom, ailleurs, ça ne lui interdirait pas de fonctionner...
Si tu ne mets pas app.path le chemin courant est le chemin d'exécution du programme.
Donc open "toto.txt" indique que le fichier est dans le dossier d'exécution du programme.
