[1.6.2/Win32] Conversion en nombres à virgule flottante de chaînes contenant des espaces

Bonjour,
J'ai téléchargé selon les adresses indiquées la version de lazarus 1.6.2 en 32 bits pour windows et pour linux.
Pas de problème pour l'instant avec la version linux mais un petit problème avec la version windows.
Dans mes petites applications j'utilise souvent la conversion de chaîne correspondant à un nombre avec décimale que convertit pour effectuer des calculs

Code:

---

1 2 3 4 5

MCREDIT:=data.bank.FieldByName('CREDIT').AsString; XCREDIT:=StrToFloat(MCREDIT); MDEBIT:=data.bank.FieldByName('DEBIT').AsString; XDEBIT:=StrToFloat(MDEBIT); XNONVALIDE:=XNONVALIDE+XCREDIT-XDEBIT;

---

comme le morceau ci-dessus où MDEBIT peut valoir ' 25,75' donc avec des espaces avant les chiffres
Jusqu'à la version 1.6.0 pas de problème de conversion sous linux ni sous windows en 32bits mais avec la dernière version j'ai un message d'erreur de conversion.
Si j'écris

Code:

---

1 2 3 4 5

MCREDIT:=data.bank.FieldByName('CREDIT').AsString; XCREDIT:=StrToFloat(Trim(MCREDIT)); MDEBIT:=data.bank.FieldByName('DEBIT').AsString; XDEBIT:=StrToFloat(Trim(MDEBIT)); XNONVALIDE:=XNONVALIDE+XCREDIT-XDEBIT;

---

donc en ajoutant une fonction supprimant les espaces plus de problème.
Je le confirme je n'avais pas de problème avec la version 1.6.0.
Un bug ou bien une idée de correction de l'unité qui contient cette fonction sous windows ?
C'est pas important mais génant si on perd des formes de programmation en cours d'évolution de lazarus et pourquoi pas de problème sous linux ?
Merci A+

C'est d'autant plus bizarre que StrToFloat est une fonction de FPC (unité SysUtils), et que les versions de FPC sont exactement les mêmes entre Lazarus 1.6.0 et Lazarus 1.6.2: à savoir FPC 3.0 dans les deux cas.

J'ajouterai qu'il me semble normal que la conversion échoue si la chaîne commence par un espace.

Merci pour vos réponses:
- concernant fpc il sne sont pas identiques sous win32 entre la version 1.6.0 et la 1.6.2 j'ai commencé à comparer les fichier *.exe et il y a des différences de date de création après je ne sais pas je tenterais de remplacer la version fpc d'1.6.2 par celle de 1.6.0.
Concernant les espaces en début de chaîne j'utilise cette méthode depuis plusieurs années sans problème que ce soit sous win32 linux i686 ou linux x86-64 et je n'ai pas de problème avec la version 1.6.2 sous linux en 32bits.
Pour l'instant je n'ai pas encore installé la version en 64 bits.
Quand j'aurais remplacé la version fpc je vous tiendrais au courant des résultats.
A+

La modification de date des fichiers .exe est peut-être due à une recompilation des binaires de FPC, mais je suis certain que c'est la même version de FPC entre Lazarus 1.6.0 et Lazarus 1.6.2.

Par ailleurs, c'est vrai qu'une vielle version de Delphi (i.e. Delphi 7), ou un appel "direct" à du code Free Pascal (c-à-d sans la LCL) autorise bien des espaces avant et/ou après pour la fonction StrToFloat (y compris pour la version de FPC venant avec Lazarus 1.6.2; ce qui confirme mon assertion précédente).

Je suppose qu'il a y a peut-être quelque chose du côté de l'initialisation des FormatSettings (il y a quelques modifs à ce niveau dans la 1.6.2, manifestement), bien que je n'imagine pas trop quelles modifications à ce niveau pourraient avoir un impact sur l'autorisation des espaces dans ce type de conversion.

Oui c'est peut-être le problème mais c'est étrange car pour toutes mes petites applications de gestion de données avec sqlite comme base je démarre l'unité principale par

Code:

---

1 2 3 4 5 6 7 8

procedure TFEnveloppes.FormCreate(Sender: TObject); begin // préparation de l'environnement defaultFormatSettings.ShortDateFormat:='DD/MM/YYYY'; defaultFormatSettings.DateSeparator:='/'; defaultFormatSettings.DecimalSeparator:=','; Preparation; end;

---

Apparemment, c'est bien un bug (du moins à mon avis): merci pour l'indication.

J'ai donc ouvert un rapport d'anomalie: http://bugs.freepascal.org/view.php?id=31072


Concrètement, vous devriez pouvoir résoudre temporairement votre problème en rajoutant l'instruction suivante dans votre phase d'initialisation:

Code:

---

defaultFormatSettings.ThousandSeparator := #$A0;

---

Note: cette modification n'est bien entendu pas très "portable" au niveau internationalisation.

Bonjour,

En fait, Ce problème est survenu depuis le passage de Lazarus à UTF8 et jusqu'à la version 1.44 où l'espace insécable était (pour le français au moins) $A0. Ce qui faisait que le formatage de nombres avec un espace insécable s'affichait avec un point d'interrogation (en particulier pour les contrôles UpDown avec séparateurs des milliers). Depuis la version 1.6.2 (je n'avais pas vérifié pour la 1.6) l'utilisation de l'espace évite ce problème. Pour mes programmes (dont la diffusion est limitée à moi-même) je mettais le séparateur des milliers à espace.

Cordialement

Merci de suivre mon petit problème.
J'ai fait de nombreux essais en copiant des fichiers d'une version dans l'autre et je suis arrivé à penser que le problème est dans le fichier lazarus.exe car si le remplace celui de la version 1.6.2 par celui de la version 1.6.0 et que supprime le fichier lazarus.cfg pour éviter le message d'erreur cela fonctionne.
Si je regarde les propriétés du fichier de la version 1.6.2 j'ai version = 1.6.1.0 étrange
A+

Salut à tous

En fait, je m'interroge sur la nécessité de la conversion, ce code me surprend:

Citation:

---

Envoyé par ovni76

Code:

---

1 2 3 4 5

MCREDIT:=data.bank.FieldByName('CREDIT').AsString; XCREDIT:=StrToFloat(MCREDIT); MDEBIT:=data.bank.FieldByName('DEBIT').AsString; XDEBIT:=StrToFloat(MDEBIT); XNONVALIDE:=XNONVALIDE+XCREDIT-XDEBIT;

---

---

n'aurais-tu pas pu écrire directement ?

Code:

---

XNONVALIDE := XNONVALIDE + data.bank.FieldByName('CREDIT').AsFloat - data.bank.FieldByName('DEBIT').AsFloat;

---

Cdlt

Oui, mais j'aime découper les opérations afin de trouver plus facilement les erreurs d'exécution ou les modifications pour une raison ou une autre. Mes petites applications me servent mais aussi à mes petits enfants donc n'ayant pas les mêmes sources d'informations je peux modeste développeur autodidacte retrouver l'endroit à adapter.
A+

Salut,

C'est plus une question de style, j'ai tendance à rendre les expressions concises tout en conservant une bonne lisibilité (enfin pour moi ;-))

Mais en passant par la propriété AsString, tu effectues une première conversion de réel vers chaîne pour ensuite convertir dans le sens inverse ... Cela fait des calculs inutiles avec les risques inhérents à la conversion que tu nous fais découvrir dans ce fil. Ton problème de conversion est assez curieux à vrai dire.

A la limite, je pourrais le comprendre la démarche si les champs de base de données DEBIT et CREDIT sont eux-mêmes de type String.

Cdlt

oui je travaille en entrée de données par l'utilisateur qu'avec des string ce qui me semble plus simple, peut-être par méconnaissance, avec l'usage de table sqlite et les composants natifs pour ce type de base. Que ce soit des nombres ou date tous est string d'où l'usage des conversions pour les calculs. Peut-être aussi liés à mes débuts dans la programmation avec usage de données sur Dbase III, Iv , V et le passage à Delphi 2 puis 4 avant Lazarus et tout cela en autodidacte ce qui peut expliquer cette forme peut-être pas très technique mais qui me donne des résultats.
A+

Salut

Mais alors, aucun de tes champs n'est typé. Tu te retrouves alors avec des données à convertir avant écriture et après lecture des champs, cela augmente la taille du code que tu dois écrire et les risques de mauvaise surprise (d'où ce fil de discussion). En outre, tu te prives de facilité offertes par SQL, par exemple pour faire la somme de toute une colonne.

Pour autant, il me semble que de DBase il y avait un type numérique.

Cdlt

Je ne me souvient pas c'est loin mais je me souviens que je devais réaliser des impressions avec mise en forme en utilisant des caractères graphiques pour créer les colonnes comme dans un tableur de nos jours mais non utilisable dans les années 80 pour imprimer une situation de matériel je devais envoyer à l'imprimante un tampon, propre au type d'imprimante comprenant par exemple : utilisateur, service, n° de série, licence, état, lieu d'utilisation etc... pour pouvoir éditer ce type de document j'utilisais des données texte d'une longueur définie et chaque texte était précédé et suivi d'un caractère graphique, chaque ligne d'une série de trait, chaque colonne d'un nom etc....
Il semble que j'ai gardé des habitudes. Depuis quelques temps j'ai abandonné les bases de type Dbase pour sqlite 3 mais je ne suis pas performant sur ce type de base et la doc en anglais ne m'aide pas, donc je "barbote" mais j'obtiens quand même les résultats espérés tant que l'on ne change pas mes habitudes bonnes ou mauvaises sans crier gare.
Aller bon Noël à tous et longue vie à Lazarus que j'aime bien et qui fonctionne aussi bien sous linux que sous windows sans trop d'adaptation.