Le répertoire par défaut est celui ou se trouve ton application, pas la racine du disque. Donc soit remplacer le premier 0 par un vRefNum ou un drive number, soit remplacer le 2e 0 par fsRtDirID qui est le dirID du répertoire racine :
Le répertoire par défaut est celui ou se trouve ton application, pas la
racine du disque. Donc soit remplacer le premier 0 par un vRefNum ou un
drive number, soit remplacer le 2e 0 par fsRtDirID qui est le dirID du
répertoire racine :
Le répertoire par défaut est celui ou se trouve ton application, pas la racine du disque. Donc soit remplacer le premier 0 par un vRefNum ou un drive number, soit remplacer le 2e 0 par fsRtDirID qui est le dirID du répertoire racine :
je ne comprends pas pourquoi... et je commence a partauger...
C'est tes 2 premiers paramètre (0 et 0) qui sont faux :
Oops, j'ai failli oublier, il faut aussi remplacer :
Str255 path="pMapsAR72.jpg";
par
Str255 path="p:MapsAR72.jpg";
pour spécifier que c'est un "partial pathname" et non pas un "full pathname".
Patrick -- Patrick Stadelmann
Fred
"Paul Guyot" a écrit dans le message de news:
In article (Dans l'article) <binafr$bg7$, "Fred" wrote (écrivait) :
Mon fichier n'existe pas??????? y'a un truc qui cloche la... j'ai pourtant un fichier du meme nom a la racine de mon disque (je suis desole mais je suis nouveau sur Mac)
Inutile d'être désolé. Pat a sans doute raison (ta chaîne pascale est foireuse, mais normalement le compilateur te donne un avertissement pour une conversion implicite de char* vers unsigned char*, non?).
Ceci dit, permets-moi d'insister, puisque tu te présentes comme nouveau sur
Mac et que tu intitules ton message "path", sur le fait que FSMakeFSSpec n'est généralement pas utilisable pour récupérer un FSSpec sur un fichier à
partir d'un chemin. Il te faut trouver le volRefNul et le dirID kivonbien, même s'il est possible d'utiliser un chemin complet (au format MacOS, les séparateurs sont des :, et tu as plein d'autres problèmes comme l'absence de garantie qu'un chemin désigne un unique élément vu que deux volumes peuvent avoir le même nom).
En général, on procède ainsi: - on détermine le FSSpec de l'application courante (on peut demander au ProcessManager) et on trouve ainsi le volRefNum et le dirID pour un fichier
à côté de l'application. - on utilise FindFolder pour trouver le dirID d'un dossier standard (préférences, dossier système).
C'est la méthode propre. Même si c'est moins vrai sous MacOS X, un chemin en dur, c'est mal, parce que c'est très non-Mac. Par exemple, un utilisateur ne s'attend pas à ce que ton logiciel ne marche plus s'il le sort du dossier Applications à la racine. Et il aura raison.
Ceci dit, les deux 0 que tu as mis devraient convenir parfaitement pour un fichier à la racine du volume par défaut.
Si tu tiens absolument à utiliser un chemin, tu peux créer un FSRef à partir d'une chaîne.
"Paul Guyot" <spam@kallisys.com> a écrit dans le message de news:
spam-53B324.13123829082003@news4-2.free.fr...
In article (Dans l'article) <binafr$bg7$1@news-reader5.wanadoo.fr>,
"Fred" <no.spam@spam.no> wrote (écrivait) :
Mon fichier n'existe pas??????? y'a un truc qui cloche la...
j'ai pourtant un fichier du meme nom a la racine de mon disque (je suis
desole mais je suis nouveau sur Mac)
Inutile d'être désolé. Pat a sans doute raison (ta chaîne pascale est
foireuse, mais normalement le compilateur te donne un avertissement pour
une conversion implicite de char* vers unsigned char*, non?).
Ceci dit, permets-moi d'insister, puisque tu te présentes comme nouveau
sur
Mac et que tu intitules ton message "path", sur le fait que FSMakeFSSpec
n'est généralement pas utilisable pour récupérer un FSSpec sur un fichier
à
partir d'un chemin. Il te faut trouver le volRefNul et le dirID kivonbien,
même s'il est possible d'utiliser un chemin complet (au format MacOS, les
séparateurs sont des :, et tu as plein d'autres problèmes comme l'absence
de garantie qu'un chemin désigne un unique élément vu que deux volumes
peuvent avoir le même nom).
En général, on procède ainsi:
- on détermine le FSSpec de l'application courante (on peut demander au
ProcessManager) et on trouve ainsi le volRefNum et le dirID pour un
fichier
à côté de l'application.
- on utilise FindFolder pour trouver le dirID d'un dossier standard
(préférences, dossier système).
C'est la méthode propre. Même si c'est moins vrai sous MacOS X, un chemin
en dur, c'est mal, parce que c'est très non-Mac. Par exemple, un
utilisateur ne s'attend pas à ce que ton logiciel ne marche plus s'il le
sort du dossier Applications à la racine. Et il aura raison.
Ceci dit, les deux 0 que tu as mis devraient convenir parfaitement pour un
fichier à la racine du volume par défaut.
Si tu tiens absolument à utiliser un chemin, tu peux créer un FSRef à
partir d'une chaîne.
In article (Dans l'article) <binafr$bg7$, "Fred" wrote (écrivait) :
Mon fichier n'existe pas??????? y'a un truc qui cloche la... j'ai pourtant un fichier du meme nom a la racine de mon disque (je suis desole mais je suis nouveau sur Mac)
Inutile d'être désolé. Pat a sans doute raison (ta chaîne pascale est foireuse, mais normalement le compilateur te donne un avertissement pour une conversion implicite de char* vers unsigned char*, non?).
Ceci dit, permets-moi d'insister, puisque tu te présentes comme nouveau sur
Mac et que tu intitules ton message "path", sur le fait que FSMakeFSSpec n'est généralement pas utilisable pour récupérer un FSSpec sur un fichier à
partir d'un chemin. Il te faut trouver le volRefNul et le dirID kivonbien, même s'il est possible d'utiliser un chemin complet (au format MacOS, les séparateurs sont des :, et tu as plein d'autres problèmes comme l'absence de garantie qu'un chemin désigne un unique élément vu que deux volumes peuvent avoir le même nom).
En général, on procède ainsi: - on détermine le FSSpec de l'application courante (on peut demander au ProcessManager) et on trouve ainsi le volRefNum et le dirID pour un fichier
à côté de l'application. - on utilise FindFolder pour trouver le dirID d'un dossier standard (préférences, dossier système).
C'est la méthode propre. Même si c'est moins vrai sous MacOS X, un chemin en dur, c'est mal, parce que c'est très non-Mac. Par exemple, un utilisateur ne s'attend pas à ce que ton logiciel ne marche plus s'il le sort du dossier Applications à la racine. Et il aura raison.
Ceci dit, les deux 0 que tu as mis devraient convenir parfaitement pour un fichier à la racine du volume par défaut.
Si tu tiens absolument à utiliser un chemin, tu peux créer un FSRef à partir d'une chaîne.
