Qqun utilise-t-il l'unité "unicode" de Mike Lischke?
Il semblerait qu'il y ait un bug dans le TWideStrings.LoadFromFile. Le
codage unicode part dans les choux.
En chargeant le fichier dans un TntMemo p.ex., c'est ok.

Jean-Pierre Lamon a écrit :
> Qqun utilise-t-il l'unité "unicode" de Mike Lischke?
> Il semblerait qu'il y ait un bug dans le TWideStrings.LoadFromFile. Le
> codage unicode part dans les choux.
> En chargeant le fichier dans un TntMemo p.ex., c'est ok.
>
>

Il n'y a pas des choses pour faire tout cela dans la JCL ?

Après mûre réflexion, BigGrizzly a écrit :
> Jean-Pierre Lamon a écrit :
>> Qqun utilise-t-il l'unité "unicode" de Mike Lischke?
>> Il semblerait qu'il y ait un bug dans le TWideStrings.LoadFromFile. Le
>> codage unicode part dans les choux.
>> En chargeant le fichier dans un TntMemo p.ex., c'est ok.
>>
>>
>
> Il n'y a pas des choses pour faire tout cela dans la JCL ?

Oui, jclunicode.pas qui possède également une classe TWideStrings. Et
là ça marche. Merci

BigGrizzly a exprimé avec précision :
> Jean-Pierre Lamon a écrit :
>> Qqun utilise-t-il l'unité "unicode" de Mike Lischke?
>> Il semblerait qu'il y ait un bug dans le TWideStrings.LoadFromFile. Le
>> codage unicode part dans les choux.
>> En chargeant le fichier dans un TntMemo p.ex., c'est ok.
>>
>>
>
> Il n'y a pas des choses pour faire tout cela dans la JCL ?

Je pense c'est une question de version. Car la base de l'unité JCL est
bien celle de Mike Lischke. Mais sans doute avec certains bugs
corrigés.

Jean-Pierre Lamon wrote:
> BigGrizzly a exprimé avec précision :
>> Jean-Pierre Lamon a écrit :
>>> Qqun utilise-t-il l'unité "unicode" de Mike Lischke?
>>> Il semblerait qu'il y ait un bug dans le TWideStrings.LoadFromFile.
>>> Le codage unicode part dans les choux.
>>> En chargeant le fichier dans un TntMemo p.ex., c'est ok.
>>>
>>>
>>
>> Il n'y a pas des choses pour faire tout cela dans la JCL ?
>
> Je pense c'est une question de version. Car la base de l'unité JCL est
> bien celle de Mike Lischke. Mais sans doute avec certains bugs corrigés.

Oui, quelques uns, même encore très récemment, c'est une unité qui
rencontre apparemment un certain succès.

OBones avait énoncé :

> Oui, quelques uns, même encore très récemment, c'est une unité qui rencontre
> apparemment un certain succès.

Tout à fait, vu les carences de Delphi dans le domaine. J'ai une
suggestion à faire : une fonction WideStringReplace. Ce serait hyper
pratique. Je m'en suis fait une, ça joue dans mes cas de figure, mais
sûrement pas dans toute l'étendue de l'unicode.

--
@+

JPL

Jean-Pierre Lamon a écrit :
> OBones avait énoncé :
>
>> Oui, quelques uns, même encore très récemment, c'est une unité qui
>> rencontre apparemment un certain succès.
>
> Tout à fait, vu les carences de Delphi dans le domaine. J'ai une
> suggestion à faire : une fonction WideStringReplace. Ce serait hyper
> pratique. Je m'en suis fait une, ça joue dans mes cas de figure, mais
> sûrement pas dans toute l'étendue de l'unicode.
>

J'ai souvenir d'en avoir utilisé une... Si ce n'est pas dans la JCL,
c'est alors dans SynEdit ?

BigGrizzly a couché sur son écran :
> Jean-Pierre Lamon a écrit :

> J'ai souvenir d'en avoir utilisé une... Si ce n'est pas dans la JCL, c'est
> alors dans SynEdit ?

Je vais regarder ça. Y'a vraiment un truc qui me dépasse pour une boîte
américaine comme Borland. Mettre le paquet sur .NET et ne même pas
avoir passé à l'unicode plus tôt. L'incidence : ben tout simplement se
priver d'une grande partie du marché, asiatique par exemple.

--
@+

JPL

Jean-Pierre Lamon a écrit :
> Je pense c'est une question de version. Car la base de l'unité JCL est
> bien celle de Mike Lischke. Mais sans doute avec certains bugs corrigés.

C'est basé sur la version de Mike Lischke mais mis à jour; avec quelques
bugs corrigés mais je travaille hardamment à en rajouter des nouveaux