Version imprimable
Bonjour,
Je viens de basculer sous Lazarus v2.0 sous Windows10 (Auparavant en v1.8.0 également sous Windows10).
Depuis ce changement, l'usage de FileExists() me retourne que le fichier (.txt) recherché n'est pas présent alors que le fichier est dans le même répertoire.
J'ai essayé avec en indiquant le chemin complet c:\... même réponse
Si quelqu'un peut m'aider, merci d'avance !!
Yop !
Il aurait été plus performant et plus efficace de nous montrer la ligne de code concerné (et ça m'aurait évité de poser la question...), sans oublier la balise "Code"Citation:
Envoyé par blackbee
Bonjour,
Pour moi (mais sous linux) ,lazarus 2.0.0RC2 je n'ai pas de problème.
Bonjour
Surement du a un problème de chaine de caractères ANSI--> UTF8 essayes d'utiliser l'unité LazFileUtils avec FileExistsUTF8
A+
Bonjour,
Problème de conversion ANSI<-->UTF8 c'est très probable, mais je n'affirmerai pas qu'il est encore utile d'utiliser les fonctions de l'unité LazFileUtils. J'utilise les versions Trunk de FPC et Lazarus mais déjà en septembre 2017 (r55800 de Lazarus) l'unité SysUtils de FPC utilisait les versions W des api de windows. Ainsi j'utilise FileExists(edNomFich.Text) où edNomFich est un champ d'édition affichant bien le nom du fichier en UTF8 contenant sans problème des caractères accentués.Citation:
Envoyé par BeanzMaster
André
Bonsoir
il semble quand même y avoir un problème (cf cette discussion) qui n'as pas été encore mise à jour dans FPC 3.0.4 mais l'est dans FPC 3.1.1 : https://bugs.freepascal.org/view.php?id=32370 A moins que je n'ai pas bien compris.
A+
Bonjour,
Si j'ai bien compris la discussion, il s'agissait surtout de savoir comment tenir compte d'un lien symbolique. Le problème semble avoir été résolu en ajoutant à la fonction une variable FollowLink optionnelle. Cela ne concerne pas la conversion ANSI<-->UTF8 qui devait être assurée dans la version précédente.
André
Bonjour
Avec Lazarus 2.1, récemment, j'ai dû remplacer un copy par un UTF8copy parce le premier découpait la chaîne "au milieu" d'un caractère double-octet.
Je n'ai plus la version 2.0 sous la main, mais je crois me rappeler qu'elle traitait de manière transparente l'UTF8, et qu'on pouvait y supprimer toutes les utilisations des fonctions suffixées ou préfixées UTF8.
Ai-je rêvé ? Ou est-ce qu'il n'y a pas eu une régression ?
Bonjour,
Si vous parlez de la fonction copy qui agit sur une chaîne ANSI, c'est normal puisque les paramètres sont des nombres d'octets et non de caractères.Citation:
Envoyé par tintinux
Dans cette discussion on parlait de fichiers. Dans la version trunc, CopyFile fonctionne correctement sur des noms de fichiers avec des caractères accentués.
André