Je ne sais pas si je suis dans le bon forum mais je pose ma question à tout
hasard :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur
un mac osx avec virtual pc. Le problème est le suivant : mon application lit
et écrit des fichiers textes tout simples mais, apparemment, Virtual PC
ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne. Ceci a
pour effet de créer une ligne vide parasite en plus de chaque ligne normale.
Evidemment, à la lecture du fichier, l'application ne s'attend pas à trouver
une ligne vide entre chaque ligne de texte et ça plante. S'agit-il d'un
problème connu de Virtual PC ? Peut-on y remédier par un paramétrage
particulier de Virtual PC ? Pour le reste, ma petite application semble
fonctionner sans problème (il s'agit d'un traceur de courbes niveau lycée et
grapheur de statistiques et de proba).
Merci de vos éventuelles contributions.
--
Un logiciel gratuit pour tracer vos courbes :
http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est un *vrai* Windows qui tourne...
Ceci a pour effet de créer une ligne vide parasite en plus de chaque ligne normale. Evidemment, à la lecture du fichier, l'application ne s'attend pas à trouver une ligne vide entre chaque ligne de texte et ça plante.
Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans un fichier de données mal généré... Du genre si il y a 2 CR de suites ou CR+LF+CR...
S'agit-il d'un problème connu de Virtual PC ?
A priori non.
Peut-on y remédier par un paramétrage particulier de Virtual PC ?
De mémoire non. VPC émule le PC pas Windows.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur
un mac osx avec virtual pc. Le problème est le suivant : mon application lit
et écrit des fichiers textes tout simples mais, apparemment, Virtual PC
ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est
un *vrai* Windows qui tourne...
Ceci a
pour effet de créer une ligne vide parasite en plus de chaque ligne normale.
Evidemment, à la lecture du fichier, l'application ne s'attend pas à trouver
une ligne vide entre chaque ligne de texte et ça plante.
Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin
de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans
un fichier de données mal généré... Du genre si il y a 2 CR de suites ou
CR+LF+CR...
S'agit-il d'un
problème connu de Virtual PC ?
A priori non.
Peut-on y remédier par un paramétrage
particulier de Virtual PC ?
De mémoire non. VPC émule le PC pas Windows.
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est un *vrai* Windows qui tourne...
Ceci a pour effet de créer une ligne vide parasite en plus de chaque ligne normale. Evidemment, à la lecture du fichier, l'application ne s'attend pas à trouver une ligne vide entre chaque ligne de texte et ça plante.
Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans un fichier de données mal généré... Du genre si il y a 2 CR de suites ou CR+LF+CR...
S'agit-il d'un problème connu de Virtual PC ?
A priori non.
Peut-on y remédier par un paramétrage particulier de Virtual PC ?
De mémoire non. VPC émule le PC pas Windows.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Patrice Rabiller
"Pierre-Alain Dorange" a écrit dans le message news: 1g7x99m.vqlcaz10gil6oN%
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est un *vrai* Windows qui tourne... Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans un fichier de données mal généré... Du genre si il y a 2 CR de suites ou CR+LF+CR...
En réalité, une analyse détaillée du fichier créé sous VPC génère, pour chaque fin de ligne CR+CR+LF, alors que sur PC ça ne se produit pas (on a seulement CR+LF). On m'a dit que ça viendrait d'une habitude dans le monde unix de traduire systématiquement LF par CR+LF. Je peux bien sûr prévoir tout ça dans mon application et ne pas tenir compte des lignes vides mais cette solution me paraît un peu bancale...
L'idéal serait pour moi, qu'il existe un compilateur Delphi (le langage que j'utilise dans le monde PC+windows) capable de produire des applications multiplateformes (c'est déjà le cas car on peut facilement créer des applications pour linux avec delphi+kylix) mais c'est une autre histoire ...
Merci pour les infos.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Pierre-Alain Dorange" <phpinfo@pas-de-pub-merci.mac.com> a écrit dans le
message news: 1g7x99m.vqlcaz10gil6oN%phpinfo@pas-de-pub-merci.mac.com...
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est
un *vrai* Windows qui tourne...
Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin
de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans
un fichier de données mal généré... Du genre si il y a 2 CR de suites ou
CR+LF+CR...
En réalité, une analyse détaillée du fichier créé sous VPC génère, pour
chaque fin de ligne CR+CR+LF, alors que sur PC ça ne se produit pas (on a
seulement CR+LF). On m'a dit que ça viendrait d'une habitude dans le monde
unix de traduire systématiquement LF par CR+LF. Je peux bien sûr prévoir
tout ça dans mon application et ne pas tenir compte des lignes vides mais
cette solution me paraît un peu bancale...
L'idéal serait pour moi, qu'il existe un compilateur Delphi (le langage que
j'utilise dans le monde PC+windows) capable de produire des applications
multiplateformes (c'est déjà le cas car on peut facilement créer des
applications pour linux avec delphi+kylix) mais c'est une autre histoire ...
Merci pour les infos.
--
Un logiciel gratuit pour tracer vos courbes :
http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Pierre-Alain Dorange" a écrit dans le message news: 1g7x99m.vqlcaz10gil6oN%
je pense pas que ça vienne de VPC, car VPC émule le PC et dessus c'est un *vrai* Windows qui tourne... Le plus simple serait peut être de prévoir ce cas dans ton "parser" afin de ne pas faire planter, car ça pourrai arriver (des lignes vides) dans un fichier de données mal généré... Du genre si il y a 2 CR de suites ou CR+LF+CR...
En réalité, une analyse détaillée du fichier créé sous VPC génère, pour chaque fin de ligne CR+CR+LF, alors que sur PC ça ne se produit pas (on a seulement CR+LF). On m'a dit que ça viendrait d'une habitude dans le monde unix de traduire systématiquement LF par CR+LF. Je peux bien sûr prévoir tout ça dans mon application et ne pas tenir compte des lignes vides mais cette solution me paraît un peu bancale...
L'idéal serait pour moi, qu'il existe un compilateur Delphi (le langage que j'utilise dans le monde PC+windows) capable de produire des applications multiplateformes (c'est déjà le cas car on peut facilement créer des applications pour linux avec delphi+kylix) mais c'est une autre histoire ...
Merci pour les infos.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
Éric Lévénez
Le 21/01/04 16:41, dans <bum6ih$4li$, « Patrice Rabiller » a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 21/01/04 16:41, dans <bum6ih$4li$1@news-reader1.wanadoo.fr>, « Patrice
Rabiller » <patrice.rabiller@wanadoo.fr> a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur
un mac osx avec virtual pc. Le problème est le suivant : mon application lit
et écrit des fichiers textes tout simples mais, apparemment, Virtual PC
ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien
comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur
Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi
cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un
émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de
contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un
problème de transfert de fichiers entre le Windows de ton Virtual PC et
l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10).
Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13).
Les fins de ligne DOS/Windows sont CR LF (13 10).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 21/01/04 16:41, dans <bum6ih$4li$, « Patrice Rabiller » a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Pascal Bourguignon
Éric Lévénez writes:
Le 21/01/04 16:41, dans <bum6ih$4li$, « Patrice Rabiller » a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes par le système de fichier utilisé pour faire la passerelle entre MS-Windows sur MS-VirtualPC et MacOSX.
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
Éric Lévénez <news@levenez.com> writes:
Le 21/01/04 16:41, dans <bum6ih$4li$1@news-reader1.wanadoo.fr>, « Patrice
Rabiller » <patrice.rabiller@wanadoo.fr> a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur
un mac osx avec virtual pc. Le problème est le suivant : mon application lit
et écrit des fichiers textes tout simples mais, apparemment, Virtual PC
ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien
comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur
Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi
cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un
émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de
contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un
problème de transfert de fichiers entre le Windows de ton Virtual PC et
l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10).
Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13).
Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce
qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes
par le système de fichier utilisé pour faire la passerelle entre
MS-Windows sur MS-VirtualPC et MacOSX.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Le 21/01/04 16:41, dans <bum6ih$4li$, « Patrice Rabiller » a écrit :
J'ai développé une application sur PC et l'un des utilisateurs l'utilise sur un mac osx avec virtual pc. Le problème est le suivant : mon application lit et écrit des fichiers textes tout simples mais, apparemment, Virtual PC ajoute un caractère 'return' (ascii13) supplémentaire à chaque ligne.
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes par le système de fichier utilisé pour faire la passerelle entre MS-Windows sur MS-VirtualPC et MacOSX.
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
pbezou
Pascal Bourguignon wrote:
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes par le système de fichier utilisé pour faire la passerelle entre MS-Windows sur MS-VirtualPC et MacOSX.
Je subodore aussi, et avec Eric, cela fait trois qui subodoront, on doit donc pas être loin de la vérité ;-)
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Ton problème dont donc être un problème annexe, comme par exemple un
problème de transfert de fichiers entre le Windows de ton Virtual PC et
l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10).
Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13).
Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce
qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes
par le système de fichier utilisé pour faire la passerelle entre
MS-Windows sur MS-VirtualPC et MacOSX.
Je subodore aussi, et avec Eric, cela fait trois qui subodoront, on doit
donc pas être loin de la vérité ;-)
--
MVP Microsoft Mac
www.makiciel.com
Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire
(Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
Il faudrait que l'OP précise où le fichier est écrit et lu? Est ce qu'il est modifié par des programmes MacOSX?
Je subodore que le problème vient d'une conversion des fins de lignes par le système de fichier utilisé pour faire la passerelle entre MS-Windows sur MS-VirtualPC et MacOSX.
Je subodore aussi, et avec Eric, cela fait trois qui subodoront, on doit donc pas être loin de la vérité ;-)
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Patrice Rabiller
Bonjour,
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Il va donc falloir que je modifie ma procédure de lecture de fichier pour tenir compte de cette particularité. Comme je ne suis pas un professionnel de la programmation (je ne suis que prof de math), je ne sais pas vraiment encore quelle méthode employer.
Merci pour vos explications.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Éric Lévénez" a écrit dans le message news: BC347353.65F42%
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi
cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Bonjour,
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran
un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se
situe le problème. Le document créé sur l'écran est un dessin mathématique
et il est enregistré non pas comme une image mais comme une suite de
définitions sous forme de lignes de texte. Je persiste à dire que mac osx
+VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR
CR LF.
Il va donc falloir que je modifie ma procédure de lecture de fichier pour
tenir compte de cette particularité. Comme je ne suis pas un professionnel
de la programmation (je ne suis que prof de math), je ne sais pas vraiment
encore quelle méthode employer.
Merci pour vos explications.
--
Un logiciel gratuit pour tracer vos courbes :
http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Éric Lévénez" <news@levenez.com> a écrit dans le message news:
BC347353.65F42%news@levenez.com...
Ceci est bien sûr totalement et techniquement impossible. Il faut bien
comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur
Virtual PC on peut émuler plein de systèmes comme par exemple unix, et
ainsi
cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un
émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de
contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un
problème de transfert de fichiers entre le Windows de ton Virtual PC et
l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable"
PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10).
Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13).
Les fins de ligne DOS/Windows sont CR LF (13 10).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Il va donc falloir que je modifie ma procédure de lecture de fichier pour tenir compte de cette particularité. Comme je ne suis pas un professionnel de la programmation (je ne suis que prof de math), je ne sais pas vraiment encore quelle méthode employer.
Merci pour vos explications.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Éric Lévénez" a écrit dans le message news: BC347353.65F42%
Ceci est bien sûr totalement et techniquement impossible. Il faut bien comprendre que Virtual PC est un émulateur de PC, pas de Windows. Et sur Virtual PC on peut émuler plein de systèmes comme par exemple unix, et ainsi
cette notion de fichier texte à la mode DOS ne peut être hard-codé dans un émulateur de matériel, c'est-à-dire un émulateur de CPU, de RAM, de contrôleur graphique...
Ton problème dont donc être un problème annexe, comme par exemple un problème de transfert de fichiers entre le Windows de ton Virtual PC et l'endroit où tu lis ce fichier (Mac OS X, Windows sur un "véritable" PC...)
Rappel :
Les fins de ligne unix et donc Mac OS X sont LF (10). Les fins de ligne Mac OS <= 9 (et certaines applis Mac OS X) sont CR (13). Les fins de ligne DOS/Windows sont CR LF (13 10).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 22/01/04 4:59, dans <bunhql$tv7$, « Patrice Rabiller » a écrit :
Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
:-(
Si tu ne nous dis pas comment tu transferts le fichier créé sous Windows/Virtual PC vers Mac OS X, on ne pourra guère t'aider.
Je te répète que VPC seul ne peut en aucun cas faire ce que tu dis. Est-ce qu'un Athlon ferait cela alors qu'un Pentium ne le ferait pas ? Non. Bien sûr. Alors une émulation d'un Pentium sur un PPC ? Hein ? Dis ?
Le problème est lors du transfert et/ou de la lecture.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/01/04 4:59, dans <bunhql$tv7$1@news-reader5.wanadoo.fr>, « Patrice
Rabiller » <patrice.rabiller@wanadoo.fr> a écrit :
Je persiste à dire que mac osx
+VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR
CR LF.
:-(
Si tu ne nous dis pas comment tu transferts le fichier créé sous
Windows/Virtual PC vers Mac OS X, on ne pourra guère t'aider.
Je te répète que VPC seul ne peut en aucun cas faire ce que tu dis. Est-ce
qu'un Athlon ferait cela alors qu'un Pentium ne le ferait pas ? Non. Bien
sûr. Alors une émulation d'un Pentium sur un PPC ? Hein ? Dis ?
Le problème est lors du transfert et/ou de la lecture.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/01/04 4:59, dans <bunhql$tv7$, « Patrice Rabiller » a écrit :
Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
:-(
Si tu ne nous dis pas comment tu transferts le fichier créé sous Windows/Virtual PC vers Mac OS X, on ne pourra guère t'aider.
Je te répète que VPC seul ne peut en aucun cas faire ce que tu dis. Est-ce qu'un Athlon ferait cela alors qu'un Pentium ne le ferait pas ? Non. Bien sûr. Alors une émulation d'un Pentium sur un PPC ? Hein ? Dis ?
Le problème est lors du transfert et/ou de la lecture.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul GABORIT
À (at) Thu, 22 Jan 2004 04:59:58 +0100, "Patrice Rabiller" écrivait (wrote):
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Dans votre application : - les fichiers sont-ils ouverts comme des fichiers textes ou comme des fichiers binaires ? - écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les deux octets de fin de ligne Windows ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Thu, 22 Jan 2004 04:59:58 +0100,
"Patrice Rabiller" <patrice.rabiller@wanadoo.fr> écrivait (wrote):
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran
un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se
situe le problème. Le document créé sur l'écran est un dessin mathématique
et il est enregistré non pas comme une image mais comme une suite de
définitions sous forme de lignes de texte. Je persiste à dire que mac osx
+VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR
CR LF.
Dans votre application :
- les fichiers sont-ils ouverts comme des fichiers textes ou comme des
fichiers binaires ?
- écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les
deux octets de fin de ligne Windows ?
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Thu, 22 Jan 2004 04:59:58 +0100, "Patrice Rabiller" écrivait (wrote):
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Dans votre application : - les fichiers sont-ils ouverts comme des fichiers textes ou comme des fichiers binaires ? - écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les deux octets de fin de ligne Windows ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
phpinfo
Patrice Rabiller wrote:
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Si le fichier est crée dans macOS X puis transférer dans VPC, là c'est possible.
Par contre si le fichier est crée dans VPC, normalement il ne doit pas y avoir de problème.
Note : on peut créer de *vrais* fichiers texte PC avec MacOS en utilisant l'éditeur de texte BBEdit qui dispose d'une option permettant de changer le type de texte (PC, Mac, Unix) en un seul clic.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran
un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se
situe le problème. Le document créé sur l'écran est un dessin mathématique
et il est enregistré non pas comme une image mais comme une suite de
définitions sous forme de lignes de texte. Je persiste à dire que mac osx
+VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR
CR LF.
Si le fichier est crée dans macOS X puis transférer dans VPC, là c'est
possible.
Par contre si le fichier est crée dans VPC, normalement il ne doit pas y
avoir de problème.
Note : on peut créer de *vrais* fichiers texte PC avec MacOS en
utilisant l'éditeur de texte BBEdit qui dispose d'une option permettant
de changer le type de texte (PC, Mac, Unix) en un seul clic.
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
Mon application fonctionne très bien sur mac osx : on peut créer à l'écran un document quelconque. On peut aussi l'enregistrer mais ... c'est là que se situe le problème. Le document créé sur l'écran est un dessin mathématique et il est enregistré non pas comme une image mais comme une suite de définitions sous forme de lignes de texte. Je persiste à dire que mac osx +VPC remplace les 2 derniers caractères CR LF (13 10) de chaque ligne par CR CR LF.
Si le fichier est crée dans macOS X puis transférer dans VPC, là c'est possible.
Par contre si le fichier est crée dans VPC, normalement il ne doit pas y avoir de problème.
Note : on peut créer de *vrais* fichiers texte PC avec MacOS en utilisant l'éditeur de texte BBEdit qui dispose d'une option permettant de changer le type de texte (PC, Mac, Unix) en un seul clic.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Patrice Rabiller
"Paul GABORIT" a écrit dans le message news:
Dans votre application : - les fichiers sont-ils ouverts comme des fichiers textes ou comme des fichiers binaires ? - écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les deux octets de fin de ligne Windows ?
Mon application lit et écrit les documents qu'elle crée sous forme de fichiers textes et non pas binaires. Elle est écrite en Delphi (c'est du pascal pour windows) à l'aide des intructions "writeln" et "readln" tout ce qu'il y a de plus simple. Les lignes écrites se terminent sur PC par les 2 caractères CR puis LF. Je ne les ajoute pas explicitement mais l'intruction writeln le fait automatiquement.
La personne qui a voulu se servir de mon application sur son mac via virtual pc a enregistré un document qu'elle m'a envoyé et ce document texte a toutes ses lignes qui se terminent par "CR CR LF". À la l'ouverture (tant sur mac+VPC que sur mon PC), il faut 2 instructions readln au lieu d'une seule pour lire chaque ligne, ce qui n'est pas prévu par le logiciel. Si vous le souhaitez, je peux vous joindre ce fichier : il est tout petit (1,28 Ko).
Merci de votre aide.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
"Paul GABORIT" <Paul.Gaborit@invalid.invalid> a écrit dans le message news:
r7smi89ye1.fsf@michelange.enstimac.fr...
Dans votre application :
- les fichiers sont-ils ouverts comme des fichiers textes ou comme des
fichiers binaires ?
- écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les
deux octets de fin de ligne Windows ?
Mon application lit et écrit les documents qu'elle crée sous forme de
fichiers textes et non pas binaires. Elle est écrite en Delphi (c'est du
pascal pour windows) à l'aide des intructions "writeln" et "readln" tout ce
qu'il y a de plus simple. Les lignes écrites se terminent sur PC par les 2
caractères CR puis LF. Je ne les ajoute pas explicitement mais l'intruction
writeln le fait automatiquement.
La personne qui a voulu se servir de mon application sur son mac via virtual
pc a enregistré un document qu'elle m'a envoyé et ce document texte a toutes
ses lignes qui se terminent par "CR CR LF". À la l'ouverture (tant sur
mac+VPC que sur mon PC), il faut 2 instructions readln au lieu d'une seule
pour lire chaque ligne, ce qui n'est pas prévu par le logiciel. Si vous le
souhaitez, je peux vous joindre ce fichier : il est tout petit (1,28 Ko).
Merci de votre aide.
--
Un logiciel gratuit pour tracer vos courbes :
http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
Dans votre application : - les fichiers sont-ils ouverts comme des fichiers textes ou comme des fichiers binaires ? - écrivez-vous une simple fin de ligne (un "n" en C) ou explicitement les deux octets de fin de ligne Windows ?
Mon application lit et écrit les documents qu'elle crée sous forme de fichiers textes et non pas binaires. Elle est écrite en Delphi (c'est du pascal pour windows) à l'aide des intructions "writeln" et "readln" tout ce qu'il y a de plus simple. Les lignes écrites se terminent sur PC par les 2 caractères CR puis LF. Je ne les ajoute pas explicitement mais l'intruction writeln le fait automatiquement.
La personne qui a voulu se servir de mon application sur son mac via virtual pc a enregistré un document qu'elle m'a envoyé et ce document texte a toutes ses lignes qui se terminent par "CR CR LF". À la l'ouverture (tant sur mac+VPC que sur mon PC), il faut 2 instructions readln au lieu d'une seule pour lire chaque ligne, ce qui n'est pas prévu par le logiciel. Si vous le souhaitez, je peux vous joindre ce fichier : il est tout petit (1,28 Ko).
Merci de votre aide.
-- Un logiciel gratuit pour tracer vos courbes : http://perso.wanadoo.fr/patrice.rabiller/SineQuaNon/menusqn.htm
