Discussion :

[SergioMaster]

Bonjour,

Alors voilà mes constatations :
Avec Lazarus
je n'ai malheureusement pas réussi à compiler/ouvrir ton programme , la faute à des chemins différents et une installation ZeosDBO que je veux garder telle quelle pour différentes raisons , mais peu importe . J'ai créer un petit projet avec les mêmes composants , déclaré les colonnes des grilles pour avoir un affichage au petit poil et


difficile de trouver la piste

J'ai donc décidé , puisque tu parlais de Delphi, d'essayer
avec Delphi 7
démarche identique et là le même problème que toi ! donc tu n'es pas
en constatant des "anomalies d'affichages" (les é,è,à,ô, etc...) j'ai flairé le piège de l'encodage et bien m'en a pris ! (c'est une partie que je maitrise mal , mais qu'il va me falloir inclure dans le tutoriel) .
Une petite connexion (via flamerobin) m'a permis de voir que la base était encodé UTF8 du coup l'idée germe ! Quelques tâtonnements (je dois l'avouer) plus tard j'ai mis la propriété clientcodepage=WIN1258 et Eurêka ID_T et ID_G réapparaissait !

le problème est donc l'encodage de la base , fonction de l'environnement de développement
ce qu'un essai avec D2010
pour D2010 , j'utilise encore la version ZEOSDBO 7.0.0 , pas de propriété clientcodepage sur le ZConnection , il a donc fallu rusé et utiliser les propriété properties
puis XE4 , ZEOS version 7.1.2

m'ont confirmé !
je suis donc aller voir ton lfm

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
object ZConnection1: TZConnection
    ControlsCodePage = cCP_UTF8
    ClientCodepage = 'UTF8'
    Properties.Strings = (
      'AutoEncodeStrings=ON'
      'codepage=UTF8'
    )

pour le comparer au mien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 object ZConnection1: TZConnection
    Connected = True
    DesignConnection = True
    HostName = 'localhost'
    Port = 0
    Database = 'F:\Cuisine\Cuisine.fdb'
    User = 'SYSDBA'
    Password = 'masterkey'
    Protocol = 'firebird-2.1'

constatations , aucune directive d'encodage : Lazarus étant utf8 tout est transparent

[Pierre GIRARD]

Le problème est que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ControlsCodePage = cCP_UTF8

se positionne automatiquement, si j'enlève cette ligne dans le lfm, elle revient automatiquement.

J'arrive effectivement à visualiser ces colonnes, mais il faut que je mette :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ClientCodepage = 'WIN1258'

Ce qui fait que :

1. Pas sur que ça soit compatible avec Linux
2. C'est pas logique, autant j'aurais compris si les éèàç... n'étaient pas affichés autant les caractères 0 à 9 ne devraient poser aucun problème.

Donc maintenant, j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
  object ZConnection1: TZConnection
    ControlsCodePage = cCP_UTF8
    ClientCodepage = 'WIN1258'
    Properties.Strings = (
      'AutoEncodeStrings=ON'
      'codepage=WIN1258'
    )
    Connected = True
    DesignConnection = True
    etc...

Mais si en conception ça semble OK, après compilation, le résultat est le même et les colonnes sont à nouveau vides, que ce soit avec UTF8 ou Win1258.

[Barbibulle]

Et il ne s'agit donc pas de limiter à deux chiffres, mais d'écrire 01 au lieu de 1. Pas impossible, mais ça demande quelque lignes de plus pour passer d'un chiffre à un string, puis de rajouter 0 devant si c'est compris entre 1 et 9. Alors que là, c'est directement bon dans 100% des cas. Surtout que si un jour je dépasse 99 ...

Quelques lignes c'est un peux exagéré, quelques caractères au plus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Format('%0:0.2u', [i] )

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure TForm1.cxButton1Click(Sender: TObject);
var i : integer;
begin
  for I := 0 to 11 do
   ShowMessage(Format('%0:0.2u', [i] ));
end;

Affichera 12 boites de dialogues avec le message :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
00
01
02
03
04
05
06
07
08
09
10
11

Ceci dit si vous ne limitez pas à 99 le problème de tri réapparaîtra pour les chiffres supérieurs à 99 ...

Donc prévoyez dès le début le max par exemple 999 et formatez vos chiffres dans la chaines avec 3 positions.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Format('%0:0.3u', [i] )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
000
001
...
010
011
...
099
100
...
999

[SergioMaster]

Le problème est que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ControlsCodePage = cCP_UTF8

se positionne automatiquement, si j'enlève cette ligne dans le lfm, elle revient automatiquement.

oui , ça c'est normal , si tu lis mon tutoriel (il me semble que j'ai indiqué cette partie là dans une mise à jour)

Donc maintenant, j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
  object ZConnection1: TZConnection
    ControlsCodePage = cCP_UTF8
    ClientCodepage = 'WIN1258'
    Properties.Strings = (
      'AutoEncodeStrings=ON'
      'codepage=WIN1258'
    )
    Connected = True
    DesignConnection = True
    etc...

Mais si en conception ça semble OK

Pour Lazarus , enlèves les properties et le clientcodepage ou alors (avec lazarus) =UTF8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  object ZConnection1: TZConnection
    ControlsCodePage = cCP_UTF8
    Connected = True
    DesignConnection = True
    etc...

devrait fonctionner

[Pierre GIRARD]

...Pour Lazarus , enlèves les properties et le clientcodepage ou alors (avec lazarus) =UTF8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  object ZConnection1: TZConnection
    ControlsCodePage = cCP_UTF8
    Connected = True
    DesignConnection = True
    etc...

devrait fonctionner

Et bien non, en supprimant "clientcodepage", c'est exactement comme avec clientcodepage=UTF8. Exactement le même résultat en conception comme après compilation, les colonnes sont vides.

[Pierre GIRARD]

Quelques lignes c'est un peux exagéré, quelques caractères au plus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Format('%0:0.2u', [i] )

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure TForm1.cxButton1Click(Sender: TObject);
var i : integer;
begin
  for I := 0 to 11 do
   ShowMessage(Format('%0:0.2u', [i] ));
end;

...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Format('%0:0.3u', [i] )

Merci pour l'info, malgré tout, il faut garder à l'esprit que converti en nom de fichier ou de répertoire, "001_Nom" et "01_Nom" c'est pas la même chose (que ce soit sur Windows ou Linux). C'est donc soit "ShowMessage(Format('%0:0.2u', [i] ))" tant que le suis en dessous de 99, soit ShowMessage(Format('%0:0.3u', [i] )) si je dépasse 100. Mais bon, j'arrive à 53, et même si je rajoute des choses ... 53 catégories en cuisine ... les bouquins de recettes dépassent rarement les 10 : Légumes, poissons, viandes, desserts et quelques autres.

Et même avec 53, il arrivent que certaines recettes sont difficiles à classer ... ou alors, il faut carrément compliquer l'application. Par exemple, "Tarte aux poireaux et aux lardons", on classe ça à :

• Tartes ?
• Légumes verts ?
• Porc ?
• ... ou les trois à la fois ?

Car si je classe à légumes verts vu qu'il y a des "poireaux", je ne la retrouverais jamais si je cherche à "tartes". C'est beaucoup plus délicat que les fameuses bases de données écoles avec "Nom", "Prénom", "Adresse" ...

Et c'est vrai pour de très nombreuses recettes. Du coup, j'ai simplifié la chose en faisant des "doublons" et en multipliant les catégories, si une recette appartient à plusieurs catégories, je la duplique (en adaptant seulement les deux premiers champs). Ainsi, je les retrouve beaucoup plus rapidement que dans des livres de recettes classiques (ce qui est bien le but final).

[Pierre GIRARD]

Pour info supplémentaire, c'est vraiment la galère cette histoire de codepage. Si j'étais Dictateur de la planète, j'imposerais définitivement un codepage donné et fixe pour tout le monde UTF8 ou UTF16 avec obligation de fournir des outils de migration pour les autres. Au pire, ne permettre QUE UTF8 et UTF16 et interdire tous les autres.

Donc, j'ai vite fait ajouté les composants IBX à mon Lazarus sur Windows ... avec exactement la même configuration que les composants IB sur Delphi.
Dans tous les cas, en configurant le "params" de IBdatabase à lc_ctype=UTF8 (comme sur les IB de Delphi) ou à lc_ctype=WIN1258) :
=> Affichage dans la DBGrid normal pour tous les champs en mode conception
=> Les deux colonnes restent vides en mode exécution

Franchement, généraliser les codages unicode éviteraient bien des prises de tête à tout le monde.

[SergioMaster]

Pour info supplémentaire, c'est vraiment la galère cette histoire de codepage. Si j'étais Dictateur de la planète, j'imposerais définitivement un codepage donné et fixe pour tout le monde UTF8 ou UTF16 avec obligation de fournir des outils de migration pour les autres. Au pire, ne permettre QUE UTF8 et UTF16 et interdire tous les autres....

Franchement, généraliser les codages unicode éviteraient bien des prises de tête à tout le monde.

Je te le fais pas dire
Ceci dit , les delphistes te rétorqueront que c'est Unicode qu'il faudrait imposer (Delphi est Unicode (UTF16?) , Lazarus UTF8) encore des querelles de clocher en perspective.
Et les chinois alors ! comme ils sont les plus nombreux ils pourraient y mettre aussi leur grain de sel "peuvent pas utiliser le français comme tout le monde eux" dirait Bidochon
Tu va avoir du mal à être élu dictateur

En fait je n'ai pas encore vraiment saisi toutes les subtilités des encodages (pour essayer d'en savoir plus http://www.firebirdsql.org/file/comm...ts-Heymann.pdf ou http://www.destructor.de/firebird/charsets.htm avec Firebird)

Avec ta base , en exécution avec D7 et Lazarus 7.1.2 (ClientCodePage=WIN1252) je n'ai pourtant pas de soucis !enfin ça coince légèrement sur le œ là , j'incriminerai plutôt la zone de définition trouble (x80 à x9F) des standards et en conséquence Firebird (cela me fait du mal de l'admettre ) le WIN1252 est la version latin 1 . Et, oui,je parle bien de firebird et non de l'affichage d'un poste selon un OS , car c'est bien Firebird qui se charge de l'encodage UTF8<->WIN1252 (enfin c'est ce que je crois comprendre , tout cela est encore très trouble pour moi)

Avec la version 7.0 pas de propriété ClientCodePage j'ai du la passer par properties codepage=WIN1252 <<< OUI 1252 pas 1258 désolé 1258 c'est vietnamien

du coup j'ai regardé la structure de ta base plus en profondeur et , qu'y vis-je ? étrangement tu as défini charset=NONE pour ces deux champs !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE DOMAIN ID_TXT2
 AS Varchar(2) CHARACTER SET NONE
 DEFAULT '__'
 NOT NULL
 COLLATE NONE;

serait-ce cela le vrai coupable de notre débauche de recherche

[SergioMaster]

Re,
Pour en revenir à lazarus , j'ai installé la dernière version sur un autre poste , la version de ZEOSDBO (donc 7.2) également
et là

conception comme exécution tout baigne

[Pierre GIRARD]

serait-ce cela le vrai coupable de notre débauche de recherche

Ben non, je ne pense pas, d'abord je viens de remplacer None par UTF8 ... et c'est pareil. En plus, je ne pense pas que Firebird soit le coupable, car avec XE2 + les composants IB, ça marche. Le problème commence dès que :

1. J'utilise les composants ZeosDbo sous XE2
2. J'utilise Lazarus, que ce soit avec ZeosDbo ou IBX (sous Windows ... car sous Linux, même avec FlameRobin, je n'arrive pas à me connecter à la base)

[SergioMaster]

J'étais rester sur une version non Unicode de Delphi (c.a.d Delphi 7)
Je viens de faire avec XE4 + ZEOSDBO 7.2 nickel sans forcer !

je ne pense pas que Firebird soit le coupable, car avec XE2 + les composants IB, ça marche.

je parlais quand on fait une conversion d'encodage c.a.d UTF8 pour la base WIN1252 pour Delphi7 (reste que les ID_G et ID_T ne m'ont pas posé de soucis) uniquement le oe

avec les version D2009 et plus , pas de décodage à faire (si ce n'est que l'on à affaire à de l'utf8 pour la base de l'utf16 pour Delphi)
cependant un test avec D2010 , Zeos 7.0 ça coince

Reste un point important , jusque là non soulevé : il s'agit de quelle version de ZEOS ? << attention je ne testerai pas la version 7.1.2 avec XE4

[Pierre GIRARD]

...Reste un point important , jusque là non soulevé : il s'agit de quelle version de ZEOS ? << attention je ne testerai pas la version 7.1.2 avec XE4

C'est la 7.1.3-stable ... celle indiquée dans le tuto (la 7.2 étant indiquée comme pas sure). Je viens de télécharger la 7.1.4.

[Pierre GIRARD]

Question subsidiaire, pour changer de version de composant, on fait comment ?

De plus, je viens de constater un truc, même en mode conception, c'est pas bon, la première ligne commence par ID_G=02 et ID_T=05 alors que le premier enregistrement de la base est : ID_G=01 et ID_T=01. Et en exécution, ça commence bien par le premier enregistrement, mais avec ID_G=(blanc) et ID_T=(blanc).

Et je me demande toujours pourquoi le string "01" peut poser problème quelque soit l'encodage choisi/utilisé/déclaré ? Encore, œ ou €, je comprends que ça puisse poser des problèmes, mais pas 0 ou 1.

[SergioMaster]

C'est la 7.1.3-stable ... celle indiquée dans le tuto (la 7.2 étant indiquée comme pas sure). Je viens de télécharger la 7.1.4.

elle n'est pas stable , cela ne veut pas dire pas "sure" , cela veut surtout dire qu'une propriété peut disparaitre d'un commit (SVN) à l'autre.

Et je me demande toujours pourquoi le string "01" peut poser problème quelque soit l'encodage choisi/utilisé/déclaré ? Encore, œ ou €, je comprends que ça puisse poser des problèmes, mais pas 0 ou 1.

le problème, si tant est, venait du charset NONE plutôt que de la string (NONE) mal transformé en UTF8

Question subsidiaire, pour changer de version de composant, on fait comment ?

on télcharge (évident) on compile (soit en écrasant l'ancienne version, soit en gardant l'ancienne sous le coude dans ces cas là on change de répertoire, et modifie l'environnement de Delphi en conséquence)

[Pierre GIRARD]

...le problème, si tant est, venait du charset NONE plutôt que de la string (NONE) mal transformé en UTF8...

Sauf que c'est changé ... et que c'est exactement pareil.

[SergioMaster]

Bonjour,

Le sujet m'étais resté en tête (et je suis têtu), de plus cette histoire d'encodage commençait à "m'escagasser", je ne digérai pas le œ des bœufs ou œufs disparus. De plus abordant le sujet d'encodage dans le tutoriel il me faut répondre à cette question

En lisant le livre de Recettes Delphi de Daniele Teti (Delphi Cookbok) dont il va falloir que je fasse certainement une critique pour le forum (je recommande vivement la version électronique du lien), un petit passage m'a envoyé vers un article très intéressant (bien qu'en anglais, encore ) mais pas récent (2003) qui m'a (enfin) fourni un explication claire concernant l'encodage et son historique

Le minimum absolu qu'un développeur doit savoir à propos de l'Unicode et des Ensembles de caractères

Bref, pour en revenir à tes recettes de cuisine cette fois, et avec la base que tu m'avais fournie, j'ai refait une certain nombre d'essais pour essayer de cerner le problème
et ce sur mon pc de dev (donc avec une ancienne version de ZEOS , Windows XP , Firebird 2.1 et D3/D7/D2010/XE4 installés)
et là surprise surprise en changeant les paramètres, tes colonnes à problème (ID_G,ID_T) me parlent "chinois" à l'exécution (D2010 codepage=UTF8) mais pas au runtime


comme une vérification de la base avec flamerobin me donne les "bonnes indications" ma conclusion actuelle est que soit ma version de ZeosDBO est en cause soit je n'ai pas encore trouvé le bon réglage, mon chapitre sur l'encodage va s'enrichir quand je vais m'y remettre (j'ai un coup de mou sur la rédaction depuis début décembre)

Meilleurs vœux

Serge

[Pierre GIRARD]

Il est clair que c'est pas simple. par contre, je me dois de corriger ma dernière intervention concernant Zeos sur Lazarus. En fait, c'est juste un fonctionnement différent entre Delphi et Lazarus.

• Avec Delphi, l'exécution sous l'EDI recompile automatiquement l'exécutable
• Avec Lazarus, l'exécution sous l'EDI exécute l'exécutable présent, même si il ne correspond plus aux source. Il faut recompiler puis exécuter (ou supprimer l'exécutable).

Donc après recompilation, c'est devenu normal.

Maintenant, bon courage dans tes recherches, car manifestement, c'est pas simple. Et l'apparition des caractères chinois est pour le moins surprenante. Par contre, même constatation, c'est bien avec les composants Zeos que les problèmes apparaissent.

[SergioMaster]

Bonjour,

Finalement, avec ta base et D7 j'ai trouvé la solution , je suis enfin parvenu à l'affichage du œ qui me désespérait.

Donc, pour résumé on a une base Firebird encodée en UTF8 que l'on veut interroger avec D7 , le problème étant que D7 n'est pas Unicode !

La solution consistait donc à indiqué que la connexion avec la base de données doit se faire avec un autre encodage. Avec les zeosdbo cela se fait par l'intermédiaire des propriétés de la connexion en indiquant CodePage=WIN1252.
Malheureusement, si c'était presque suffisant il restait que le œ restait un désespérant | restait à savoir pourquoi
En fait pour cela il faut se pencher sur la table des caractères ASCII que je qualifierais de "normale" et horreur le œ n'existe pas dans la police de caractères utilisée par défaut pour un programme D7 c.a.d. MS Sans Serif

Passé cette constatation, c'est alors devenu limpide : "Et si je changeai de police de caractères ?"
Sitôt pensé sitôt fait, passage de la grille en font=Arial (après d'autres recherches MS reference 1,2 etc.. fonctionnent aussi) et œ s'affiche sans complexe.
Resterai bien sûr à contrôler la saisie, sauf que là, vous allez rire : c'est moi qui ne sait pas écrire un œ avec mon clavier (pour tous ceux du texte que vous lisez je triche grâce a un copier coller)
Plus sérieusement , après quelques tâtonnements j'ai retrouvé le œ de mon clavier (Alt+0156) et la saisie fonctionne

Conclusion : je suis têtu

[Ph. B.]

Bonjour,

En fait pour cela il faut se pencher sur la table des caractères ASCII que je qualifierais de "normale" et horreur le œ n'existe pas dans la police de caractères utilisée par défaut pour un programme D7 c.a.d. MS Sans Serif

Passé cette constatation, c'est alors devenu limpide : "Et si je changeai de police de caractères ?"
Sitôt pensé sitôt fait, passage de la grille en font=Arial (après d'autres recherches MS reference 1,2 etc.. fonctionnent aussi) et œ s'affiche sans complexe.

Cela arrive à des outils bien plus récents que D7 : http://www.developpez.net/forums/d14...ctere-special/

Resterai bien sûr à contrôler la saisie, sauf que là, vous allez rire : c'est moi qui ne sait pas écrire un œ avec mon clavier (pour tous ceux du texte que vous lisez je triche grâce a un copier coller)
Plus sérieusement , après quelques tâtonnements j'ai retrouvé le œ de mon clavier (Alt+0156) et la saisie fonctionne

Il suffisait d'utiliser la "Table de caractères" accessible dans les "tous les programmes > Accessoires > Outils système"

Conclusion : je suis têtu

J'aurais dit : Persévérant

[Pierre GIRARD]

...Conclusion : je suis têtu

Ou persévérant ... mais c'est le résultat qui compte. Pour ma part, mes polices fétiches sont "Palatino Linothype", "Verdana" et "Courrier New". Je déteste Arial que je trouve particulièrement laid et "MS Sans Serif " est infiniment moins élégant que "Palatino Linothype". J'utilise ces polices aussi bien sur Windows que sur Linux sans trop de problèmes.

L'important reste d'avoir une explication et montre que ces histoires de polices, couplé aux encodages + Bases de données + claviers + ... c'est jamais simple.

Merci pour tes recherches ... mon cousin très éloigné