Problème test sur ensemble

Bonjour,

Je teste comme à l'habitude le KeyPress lors de saisie, mais là, je ne sais pas pourquoi, le compilateur me fait une erreur:

Code:

---

1 2 3 4 5 6 7

procedure TForm1.EdNombreKeyPress(Sender: TObject; var Key: char); begin Case TypeSaisie of tsNombre : if Not (Key in ['0'..'9',#9]) then Key := #0; tsRecord : if Not (Key in ['0'..'9','a'..'z','A'..'Z','é','è','ç','à','ï','î','â','ä','ù','ô',#9]) then Key := #0; end; end;

---

je vous mets l'image car l'éditeur souligne l'endroit où il coince, juste avant la première lettre accentuée! Est-ce le codage en unicode qui complique les choses?
Pièce jointe 633202

Et le message du compilateur:
Pièce jointe 633203

Est-ce que ça signifie que j'ai dépassé les capacités d'énumération de l'ensemble: on parle de LongInt, ce qui me parait peu probable!
Si vous avez une idée? Je vais essayer de décomposer en deux ensembles distincts...

Bon, le Type SET n'est valable que pour les types de base en Lazarus, il faut donc procéder autrement...

Merci

Bonjour,

Tu ne donnes pas ta version de LAZARUS mais je supposes que c'est une version UTF8 donc tes caractères accentués sont en UTF8 et font donc plus d'un octet ce que ne permet pas l'ensemble

Cordialement

Bonjour acaumes
Oui, j'ai la dernière version de Lazarus 2.2.4,

Citation:

---

c'est une version UTF8 donc tes caractères accentués sont en UTF8 et font donc plus d'un octet ce que ne permet pas l'ensemble

---

oui, c'est ce que j'ai compris, il faut passer par l'unicode, il faut donc trouver une fonction qui accepte certains caractères d'une table pour vérifier la saisie ou bien essayer avec un tableau de constantes ou un ensemble énuméré, je ne sais pas!

Peut-être en créant un String tout simplement : CarSpec = "ÀÁÂÃÄÅàáâãäåÒÓÔÕÖØòóôõöøÈÉÊËèéêëÌÍÎÏìíîïÙÚÛÜùúûüÿÑñÇç "

Merci

Ou en testant la catégorie du caractère.

Code:

---

1 2 3 4

procedure TForm1.Edit1UTF8KeyPress(Sender: TObject; var UTF8Key: TUTF8Char); begin if not (TCharacter.IsLetterOrDigit(UTF8Decode(UTF8Key), 1) or (UTF8Key = #9)) then UTF8Key := #0; end;

---

Ainsi tu t'affranchis du problème de langue ;)

Merci Andnotor génial, tu as réponse à tout!:ccool:

Je découvre avec stupeur, cette géniale unité Caracter.pass
Il manque vraiment un bouquin pour y voir clair dans cette masse d'information

Bon, bien que j'ai peu de temps, j'ai décidé de rédigé des petites applis ou Faq pour les éternels débutants comme moi! Parce qu'avec des petits exemples, on retrouve plus facilement les sources du code et des fonctions que l'on ne soupçonne pas.
par exemple, dans mes anciennes unités de Delphi, j'ai des fonctions pour reconnaître un nombre entier, d'un Digit etc... Cette unité a plein de fonctions utiles apparemment
J'avais justement une question à propos des surogates dont tu parlais dans notre dernier échange. J'ai eu beau chercher une définition claire, je n'ai pas trouvé. Est-ce que ce sont des signes ajoutés autour de certains caractères très spéciaux qui en modifient le sens. Comme des caractères arabes ou chinois?

Citation:

---

Envoyé par Andnotor

Ou en testant la catégorie du caractère.
Ainsi tu t'affranchis du problème de langue ;)

---

Non les surrogates sont le résultat de calculs qui vont systématiquement tombés dans la rangée $D800 à $DFFF (une zone qui historiquement ne contenait aucun symbole).

Les surrogates sont constitués de 6 bits fixes (high: 110110, low: 110111) et 10 de données. L'ensemble forme une paire (surrogate pair) contenant au total 12 bits de prefix et 20 bits de données. Les 4 bits de poids fort de la donnée représentent le plan (la table), il reste 16 bits pour le code. Ce qui fait 17 plans différents en comptant celui de base contenant chacun 65535 codes (en gros). Bref, un paquet de possibilités ;)

Ca parait compliqué mais est finalement assez logique pour des questions de rapidité de traitement.
Avoir juste un signe de début comme tu le mentionnes (représentant un plan, une table) impliquerait que lorsqu'on indexe une chaîne le mot (16 bits) précédent soit systématiquement testé puisque le mot courant représenterait un symbole différent en fonction du plan.

Dans le standard unicode, il n'y a que si tu tombes sur un low surrogate (entre $DC00 et $DFFF) que tu devras lire le mot précédent, respectivement suivant pour le high surrogate ($D800 à $DBFF), il y a donc traitement "lourd" que pour ces cas précis et non sur tous les codes de la chaîne.

Et même en chinois, les symboles les plus courants se retrouvent dans le plan de base (<$FFFF) ne demandant ainsi aucun traitement particulier (de mémoire, 6000 symboles suffisent à l'écrit courant).