Mise en forme de fichier source Panoramic (nième version)

J'ai fait un petit programme pour évaluer cela. Le "_" passe avant majuscules et minuscules, les majuscules passent avant les minuscules, mais effectivement, on a _AaBbCc... .Voici la petite démo:

Code:: label trier, ajouter

list 10 : top 10,40 : left 10,10 : width 10,200 : height 10,200
button 20 : top 20,10 : left 20,10 : caption 20,"Trier" : on_click 20,trier
edit 30 : top 30,260 : left 30,10 : width 30,200
button 40 : top 40,260 : left 40,240 : caption 40,"Ajouter" : on_click 40,ajouter

end

trier:
sort_on 10
sort_off 10
return

ajouter:
item_add 10,text$(30)
return

Et pourquoi ne pas tester systématiquement UPPER$(mot_clé) - ainsi il n'y a pas d'ambiguïté. De toute façon, en Panoramic, "on_click", "ON_CLICK", "On_Click" etc sont identiques. Alors, tu pourrais bien travailler uniquement avec UPPER$(...) pour le traitement ET les tris, et il n'y a plus de problème ?

Bonsoir Klaus,

Ben non ca ne suffira pas car pour contrôler les mots-cles je fais une comparaison ASCII et par dichotomie (pour gagner du temps) dans la liste.

Meme en faisant un UPPER$ cela ne marchera pas.

Par exemple, un classement par niveau ASCII:
FILEBIN_....
FILE_WRITE

Classement de la LIST par SORT:
FILE_WRITE
FILEBIN

pourtant le caractère _ (asc.95) est superieur à B (asc.66)

EDIT: J'ai bien une solution (tri manuel) mais cela ne me convient pas encore car ça rame trop....

J'entends bien, mais je ne vois toujours pa le problème. Pourquoi la liste de référence (celle dans laquelle tu cherches) n'est pas triée de la même manière ? Et si tu utilises un DLIST qui est peut-être trié différemment, alors tu peux utiliser un LIST caché par HIDE à la place...

Pour ma recherche, par exemple j'ai le mot FILE_READLN et je veux vérifier si il est dans ma liste.

Je part du point milieu de la liste: n/2
si FILE_READLN > mot(n/2)
je prend le point milieu de [n/2 - n] et je relance la recherche
sinon si <
je prend le point milieu de [ 0 à n/2] et je relance la recherche
sinon
j'ai trouvé !!
finsi

à un moment donné j'ai ceci dans ma DLIST :
FILE_READBUF
FILE_READLN
FILE_RENAME
FILE_SAVE
FILE_WRITE
FILE_WRITEBUF
FILE_WRITELN
FILEBIN_BLOCK_READ <- mon point milieu
FILEBIN_BLOCK_WRITE
FILEBIN_CLOSE
FILEBIN_HEXA_READ
FILEBIN_HEXA_WRITE
FILEBIN_OPEN_READ
FILEBIN_OPEN_WRITE
FILEBIN_POS()

ma comparaison ascii me dit que FILE_READLN est superieur à FILEBIN_BLOCK_READ (ce qui est vrai!)
donc je zappe tout ce qui se trouve en dessous de mon point milieu et je relance la recherche entre FILEBIN_BLOCK_READ et la fin de la liste. or dans ma DLIST FILE_READLN se trouve en dessous de FILEBIN_BLOCK_READ...

Autant pour moi. Essaie avec LOWER$(...) !
ASC("_") évalue à 95, et ASC(LOWER$("_")) évalue également à 95
alors que ASC(LOWER$("A") évalue à 97
et ta dichotomie marchera.

ok merci klaus j'essayerai demain ce que tu dis, pour l'instant dodo !
Sleep

voici une version légèrement adaptée de mon programme, qui montre le principe:

Code:: label trier, ajouter, ajouter_liste

dim s$, i%

data "FILE_READLN","FILE_RENAME","FILEBIN_OPEN_WRITE"
data "FILE_SAVE","FILE_WRITE","FILE_WRITEBUF"
data "FILEBIN_BLOCK_READ <- mon point milieu","FILEBIN_BLOCK_WRITE"
data "FILEBIN_CLOSE","FILEBIN_HEXA_READ","FILE_WRITELN","FILE_READBUF"
data "FILEBIN_HEXA_WRITE","FILEBIN_OPEN_READ","FILEBIN_POS()"
data "*"
height 0,800

list 10 : top 10,40 : left 10,10 : width 10,200 : height 10,200
button 20 : top 20,10 : left 20,10 : caption 20,"Trier" : on_click 20,trier
edit 30 : top 30,260 : left 30,10 : width 30,200
button 40 : top 40,260 : left 40,240 : caption 40,"Ajouter" : on_click 40,ajouter
list 50 : top 50,290 : left 50,10 : width 50,200 : height 50,200
button 60 : top 60,330 : left 60,240 : caption 60,"Ajouter" : on_click 60,ajouter_liste

read s$
repeat
item_add 50,s$
read s$
until s$="*"

end

trier:
sort_on 10
sort_off 10
return

ajouter:
item_add 10,lower$(text$(30))
text 30,""
return

ajouter_liste:
for i%=1 to count(50)
item_add 10,lower$(item_read$(50,i%))
next i%
return

En ajoutant l'ensemble des lignes de ton exemple, dans n'importe quel ordre, et en triant à la fin, tu obtiens bien une liste triée convenablement, avec le "_" étant plus petit que n'importe quelle lettre. Je pense que c'est la solution.

Si tu cliques sur Ajouter à côté de la liste de tes mots-clé (volontairement dans le désordre), elle se charge dans la liste du haut, en minuscules. Si tu cliques ensuite sur Trier, la liste se trie, et je pense que ton algorithme de dichotomie marchera sur la liste ainsi triée.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

N'empêche que ce sont des pis-aller, mais que le bug est bien là. Et les majuscules ne passent pas avant les minuscules, c'est un peu n'importe quoi.
Je reprends ton exemple, Klaus, en ajoutant avant le end:

Code:: label trier, ajouter

list 10 : top 10,40 : left 10,10 : width 10,200 : height 10,200
button 20 : top 20,10 : left 20,10 : caption 20,"Trier" : on_click 20,trier
edit 30 : top 30,260 : left 30,10 : width 30,200
button 40 : top 40,260 : left 40,240 : caption 40,"Ajouter" : on_click 40,ajouter
item_add 10,"A"
item_add 10,"B"
item_add 10,"a"
item_add 10,"A"
end

trier:
sort_on 10
sort_off 10
return

ajouter:
item_add 10,text$(30)
return

on obtient: a, A, A, B
l'ordre alphabétique est bien respecté, mais majuscules et minuscules sont bien indifférenciées.

Oui, certes. majuscules et minuscules sont bien différents. C'est pourquoi, dans mon dernier programme, je propose bien de tout passer en LOWER$ au moment de ITEM_ADD. Bien sûr, ce n'est qu'une solution pour le cas précis d'identification des mots-clé, car ils sont effectivement insensibles à la casse. je suis d'accord pour dire que cela ne peut pas constituer une solution générale pour trier une liste. Là, il y a un vrai problème. Mais pour Nardo26, c'est la solution à son problème spécifique.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Il y a aussi, ce que je faisais avant de connaitre le SORT Panoramic, utiliser la fonction SORT du Dos (c'est à dire File_save du List dans un fichier temporaire, SORT du fichier dans lui-même, puis File_load), c'est très rapide et efficace.
Mais je reconnais que c'est un peu lourd, et puis il y a cette agaçante fenêtre noire qui apparaît fugitivement.

N'importe, il y a un bug qui devra être réparé. (c'est le mauvais Sort qui a frappé Very Happy

)

Ca doit être l'ordre de tri sous Windows. J'ai essayé avec une listbox sous Visualbasic, et le problème est le même: la suite (a,_,A) est triée en (_,A,a). Le "_" passe donc bien avant les lettres majuscules, alors que le code ASCII est plus élevé. Il faudra le savoir et faire avec.

Ce petit programme montre le véritable ordre de tri des caractères:

Code:: dim i%
list 10 : top 10,10 : left 10,10 : height 10,200
for i%=32 to 254
item_add 10,chr$(i%)+" = " + str$(i%)
next i%
sort 10
end

Sans commentaire. Juste à savoir.

Bonjour Klaus,

Concernant la boucle de 32 à 254, j'ai déjà fait l'essai : c'est assez bizarre comme résultat non ? drunken

Concernant le lower$():
Cela ne fonctionne pas car je souhaiterai que le caractère '_' soit supérieur à z,Z (ordre naturel ascii) donc dans la liste:
FILE_xxx doit normalement se trouver après FILEBIN_xxx

Ce qui n'est pas le cas dans la list, même en passant tout en lower$

La seule chose que je peut faire c'est :
Au lieu de faire un FILE_LOAD MaDLIST, "ListeDesMotsClé.txt", il faut que j'ouvre le fichier , de faire un FILE_READLN de chaque élément et de faire un tri manuel en utilisant ma fonction strcmp de comparaison de chaine...
C'est la seule façon pour obtenir un ordre dans ma liste compatible avec strcmp. --> Le problème c'est que ça rame !

Autre solution : J'essaye de voir pour adapter ma fonction strcmp par rapport au caractère '_'
...

Invité

Est-ce que cela vous convient le résultat (sortie sur une 2ème liste pour comparer)

Code:: dim i% ,v,a$ ,a
height 0,550
list 10 : top 10,10 : left 10,10 : height 10,200
for i%=32 to 254
item_add 10,chr$(i%)+" = " + str$(i%)
next i%
sort 10

data "FILE_READLN","FILE_RENAME","FILEBIN_OPEN_WRITE"
data "FILE_SAVE","FILE_WRITE","FILE_WRITEBUF"
data "FILEBIN_BLOCK_READ <- mon point milieu","FILEBIN_BLOCK_WRITE"
data "FILEBIN_CLOSE","FILEBIN_HEXA_READ","FILE_WRITELN","FILE_READBUF"
data "FILEBIN_HEXA_WRITE","FILEBIN_OPEN_READ","FILEBIN_POS()"
data "*"
list 1:left 1,100:height 1,500 :font_size 1,10:width 1,200
list 2:left 2,320:height 2,500 :font_size 2,10:width 2,200
a$=""
repeat
read a$ :a$=lower$(a$):if a$="*" then exit_repeat
v=instr(a$,"_") :if instr(a$,"_")>0 then a$=left$(a$,v-1) + chr$(91) + mid$(a$,v+1,len(a$))
item_add 1,a$
until a$="*"
wait 2000
sort 1
message chr$(91)+" "+upper$(chr$(91))
for a= 1 to count(1)
a$=upper$(item_read$(1,a))
v=instr(a$,chr$(91))
if v>0 then a$=left$(a$,v-1)+"_"+mid$(a$,v+1,len(a$))
item_add 2,a$
next a
end

Merci cosmos pour ton aide,

Voila ce que j'ai dans la DLIST (et dans l'exemple que tu as fourni)
FILE_READBUF
FILE_READLN
FILE_RENAME
FILE_SAVE
FILE_SYSTEM
FILE_SYSTEM_OFF
FILE_WRITE
FILE_WRITEBUF
FILE_WRITELN
FILEBIN_BLOCK_READ
FILEBIN_BLOCK_WRITE
FILEBIN_CLOSE

Et normalement, voila ce qu'il devrait y avoir si on s'en tient aux codes ASCII pour l'ordre de tri:

FILEBIN_BLOCK_READ
FILEBIN_BLOCK_WRITE
FILEBIN_CLOSE
FILE_READBUF
FILE_READLN
FILE_RENAME
FILE_SAVE
FILE_SYSTEM
FILE_SYSTEM_OFF
FILE_WRITE
FILE_WRITEBUF
FILE_WRITELN

car : asc("_") > asc("B") Wink

J'ai trouvé la solution: j'ai modifié ma procédure de comparaison de chaine :

Code:: ' ------------------------------------------------------------------------------
' Comparaison de deux chaine de caractères :
' Appel : strcmp_s1$ = "Aea" : strcmp_s2$ = "Aeb" : gosub strcmp
' Retour: -1: [s1$ < s2$] 0: [s1$ = s2$] 1: [s1$ > s2$]
' ------------------------------------------------------------------------------
strcmp:
IF VARIABLE("strcmp_a1")=0
DIM strcmp_a1, strcmp_a2
END_IF
strcmp=1
WHILE MID$(strcmp_s1$, strcmp, 1)= MID$(strcmp_s2$, strcmp, 1)
IF ((strcmp = LEN(strcmp_s1$)) OR (strcmp = LEN(strcmp_s2$)))
IF LEN(strcmp_s1$)<> LEN(strcmp_s2$)
strcmp = SGN(LEN(strcmp_s1$)- LEN(strcmp_s2$))
ELSE
strcmp=0
END_IF
RETURN
END_IF
strcmp =strcmp +1
END_WHILE
' traitement particulier du caractère "_" : on fait en sorte qu'il soit inferieur à "A"
strcmp_a1= ASC(MID$(strcmp_s1$, strcmp, 1)) : IF strcmp_a1 =95 THEN strcmp_a1=64
strcmp_a2= ASC(MID$(strcmp_s2$, strcmp, 1)) : IF strcmp_a2 =95 THEN strcmp_a2=64
strcmp = SGN(strcmp_a1-strcmp_a2)
RETURN

En fait c'était tout bête... Neutral

Cela a quand même permis de constater qu'il ne faut pas faire confiance à la commande SORT... Wink

PS: J'ai mis à jour le source (voir lien 1er post)

Merci à tous de vous êtes creusés la tête sur ce pb... Very Happy

Note : ma procédure strcmp fonctionne uniquement que pour mon cas particulier (list des mots clé) qui ne contient que [A-Z][0-9][_$]

Note2: pour l'ordre de tri, tu as raison Klaus, j'ai pas encore trouvé de doc parlant de ce sujet...
Le plus étonnant c'est que quand on regarde sur le net, tout le monde passe par une comparaison du code ascii...
même les sources de strcmp...

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Mes certitudes s'effondrent ! après essai, je m'aperçois que le Sort du Dos fait la même chose, pas de distinction des majuscules et minuscule, et l'underscore ('_') se retrouve classé entre l'espace et les chiffres... affraid

Invité

Quel con je suis !
Il faut remplacer chr$(91) par chr$(39), et apparemment cela donne le même résultat que ta demande. Embarassed

Évidemment ce n'est valable que dans ce cas.

Citation :: Merci cosmos pour ton aide,

Pas de quoi pour dire n'importe quoi!

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Le tri, c'est n'importe quoi. Si on compare les deux méthodes, Panoramic et MsDos (tri de la liste des caractères Ascii de 32 à 255):

Code:: dim f$, f1$, f2$, i%
HEIGHT 0, 900: WIDTH 0, 250
LIST 1: TOP 1, 20: HEIGHT 1, 840: WIDTH 1, 90
LIST 2: TOP 2, 20: HEIGHT 2, 840: LEFT 2, 100: WIDTH 2, 90
PRINT "Tri Panoramic Tri MsDos"
f1$ = "C:\Temp\Test.txt"
f2$ = "C:\Temp\Tri.tmp"
File_open_write 1, f1$
for i% = 32 TO 255: file_writeln 1, chr$(i%)+" "+str$(i%): next i%
File_Close 1
Font_Name 1, "Courier New": Font_Name 2, "Courier New": FILE_LOAD 1, f1$: FILE_LOAD 2, f1$
MESSAGE "Lancer le tri !"
SORT 1
EXECUTE_WAIT "Cmd.exe /c SORT " + f1$ + " /O " + f2$
FILE_LOAD 2, f2$: FILE_DELETE f2$: FILE_DELETE f1$
end

les résultats sont différents, et aussi faux l'un que l'autre (on devrait retrouver les listes inchangées, puisqu'elles sont déjà classées).

Je suis convaincu que ce n'était pas comme ça autrefois, sous le vrai MsDos, et que c'est l'émulateur Dos de Windows qui déconne.

Bonjour à tous !

@cosmos : Mise en forme de fichier source Panoramic (nième version) - Page 2 45

L'essentiel c'est de participer !!!

Sinon j'ai peut être un début d'explication (pour un autre language et dans une autre langue...)

Désolé pour le manque de traduction, je suis trop nul pour cela !!
En gros, il peut y avoir également des critères de tri en fct de la langue...
... c'est pas gagné !!! Wink

Citation :: In summary, strcmp() does not necessarily use the ASCII code order of each character like in the 'C' locale, but instead parse each string to match language-specific character entities (such as 'ch' in Spanish, or 'dz' in Czech), whose collation order is then compared. When both character entities have the same collation order (such as 'ss' and '�' in German), they are compared relative to their code by strcmp(), or considered equal by strcasecmp().
The LC_COLLATE locale setting is then considered: only if LC_COLLATE=C or LC_ALL=C does strcmp() compare strings by character code.
Generally, most locales define the following order:
control, space, punctuation and underscore, digit, alpha (lower then upper with Latin scripts; or final, middle, then isolated, initial with Arabic script), symbols, others...
With strcasecmp(), the alpha subclass is ignored and consider all forms of letters as equal.
Note also that some locales behave differently with accented characters: some consider they are the same letter as the unaccented letter (with a minor collation order, e.g. French, Italian, Spanish), some consider they are distinct letters with an independant collation order (e.g. in the C locale, or in Nordic languages).
Finally, the collation string is not considering individual characters but instead groups of characters that form a single letter:
- for example "ch" or "CH" in Spanish which is always after all other strings beginning with 'c' or 'C', including "cz", but before 'd' or 'D';
- 'ss' and '�' in German;
- 'dz', 'DZ' and 'Dz' in some Central European languages written with the Latin script...
- UTF-8, UTF-16 (Unicode), S-JIS, Big5, ISO2022 character encoding of a locale (the suffix in the locale name) first decode the characters into the UCS4/ISO10646 code position before applying the rules of the language indicated by the main locale...
So be extremely careful to what you consider a "character", as it may just mean a encoding byte with no significance in the string collation algorithm: the first character of the string "cholera" in Spanish is "ch", not "c" !

source : voir ici

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Bon, autrement dit c'est n'importe quoi, si on ne respecte pas le code Ascii, on ne peut plus se fier à personne !
Il n'y a plus qu'à s'écrire son propre algorithme de tri. C'est pas gagné !

De retour de voyage, j'ai lu l'ensemble des interventions depuis mon dernier post dans ce sujet. Je pense que le message de Nardo26 explique parfaitement le phénomène. Donc, seule solution: remplacer SYSTEMATIQUEMENT le '_' par un chr$(255) (ou similaire), aussi bien dans ta liste de référence (à faire une seule fois) que pour chaque mot-clé à tester. Un simple GOSUB juste avant la dichotomie, et le tout est joué.

Mais ce serait peut-être l'occasion de suggérer à Jack de fournir des fonctions de comparaison de chaînes, retournant -1, 0 ou 1 selon que le résultat est plus petit, égal ou plus grand, avec un paramètre indiquant le mode de comparaison, comme ceci:

Code:: resultat% = strcomp(s1$,s2$[,mode%)])

avec
mode%=0 comparaison standard Windows/Dos (défaut)
mode%=1 comparaison ASCII stricte
mode%=2 ...

Tout à fait d'accord avec toi Klaus ! Smile

Il manque queleques instructions pour les chaines.
STRCOMP, RINSTR, etc...

Je continu à faire des recherches concernant cet ordre quand même bizarroïde... le pourquoi du comment...

Concernant la solution, j'ai fait l'inverse dans ma procedure de comparaison :
j'ai remplacé/simulé le code ascii de '_' par un code plus petit de manière à être en concordance avec le tri de la DLIST...

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Ou alors pouvoir comparer deux chaînes, ce qu'on pouvait faire en QBasic:
IF a$ > b$ THEN ...

Oui, mais là encore, se pose la question sur quel critère on compare. Valeurs ASCII des caractères ? collection de caractères dépendant de la langue locale ? dependant d' d'un code page su système ? Il faudrait alors ajouter une commande STRING_COMPARE_MODE option% pour pouvoir choisir ce mode, sinon, on aexactement le même dilemme.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Pour moi, j'ai toujours considéré que c'était l'ordre Ascii des caractères, ça m'a toujours paru si évident que je ne me suis jamais posé la question avant !
Mais Nardo a ébranlé mes belles certitudes... et également l'expérience, maintenant...

Désolé JL35... Neutral

Ca me parait bien compliqué le STRING_COMPARE_MODE, surtout que l'on s'est jamais posé la question jusqu'à maintenant.

Actuellement, l'ordre de tri est sensiblement le même que l'ordre ASCII, en dehors des caractères spéciaux (+/-*_'"# etc..)

Si Jack nous ajoute des fonctions de comparaison de chaine qui s'appuient sur les même critères que les fonctions SORT des (D)LIST, cela me conviendrai parfaitement...

Ou alors il y a cette solution :

Code:: LABEL strcmp:DIM strcmp_s1$,strcmp_s2$,strcmp
LABEL CreateNewObject

strcmp_s1$="a" : strcmp_s2$="b" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)
strcmp_s1$="FILE_WRITE" : strcmp_s2$="FILEBIN" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')= "+str$(strcmp)
strcmp_s1$="FILEBIN" : strcmp_s2$="FILE_WRITE" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')= "+str$(strcmp)
strcmp_s1$="_" : strcmp_s2$="A" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)
strcmp_s1$="_" : strcmp_s2$="a" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)

END

strcmp:
if Variable("strcmp_list")=0 then dim strcmp_list
if strcmp_s1$=strcmp_s2$
strcmp=0
else
GOSUB CreateNewObject:strcmp_list=CreateNewObject
DLIST strcmp_list
ITEM_ADD strcmp_list,strcmp_s1$:ITEM_ADD strcmp_list,strcmp_s2$
SORT strcmp_list
if (strcmp_s1$=ITEM_READ$(strcmp_list,1)): strcmp=-1: else: strcmp=1 :end_if
DELETE strcmp_list
end_if
RETURN

CreateNewObject:
IF variable("CreateNewObject")=0
DIM CreateNewObject
END_IF
CreateNewObject=1
WHILE OBJECT_EXISTS(CreateNewObject)=1
CreateNewObject=CreateNewObject+1
END_WHILE
return

» Mise en forme de source Panoramic
» Mise en forme de sources Panoramic (bis)
» Analyse d'un source - Version 2.1
» Analyse/Mise en forme de sources
» Autre tentative de mise en forme des nombres