Amélioration de la reconnaissance des constantes "..."

Je n'ai pas voulu mettre cela dans les bugs, mais pour moi, ce n'en est pas loin. En tout cas, la gestion des constantes de chaînes de caractères est plus que perturbante et productrice d'anomalies. Je m'explique:

Lorsqu'un affecte une constante de type chaîne de caractères (genre "xxx") à un objet, seul l'intérieur de la constante est mis en place, pas les guillemets. Soit - c'est normal. Mais si je veux mettre les guillemets, comment faire ? Je sais que ce problème a déjà été débattu dans ce forum. Mais il n'y a toujours pas de solution "simple". En effet, je peux facilement doubler les guillemets comme dans l'exemple suivant:

Code:

edit 1
s$ = "abc"
text 1,chr$(34)+chr$(34)+s$+chr$(34)+chr$(34)

Pas beau, mais ça marche.

Mais quoi faire si les guillets sont dans s$? Ils qeront automatiquement enlevés. Et c'est là que le bât blesse. Le contenu de la variable s$ devrait être respecté. Si je veux mettre s$ dans un edit, actuellement, il faut que je fasse comme ceci:

Code:

if left$(s$,1)=chr$(34)
  text 1,chr$(34)+chr$(34)+s$+chr$(34)+chr$(34)
else
  text 1,s$
end_if

Et là, je trouve ça inadmissible ! On peut utiliser s$ et les guillemets sont présents et reconnaissables, tout comme les données d'objets comme text$(N) ou grid_read$(N,lig,col), mais on ne peut ni affecter ces informations à une variable ni les placer dans un autre objet, sans que les quillemets soient supprimés. Seule la construction ci-dessus permet de rectifier cela.

Donc, mon souhait serait qu'une chaîne de caractères, quelque soit sa provenance, puisse être chargée dans une variable, dans un objet, utilisée dans la commande MESSAGE etc sans que les guillemets entourant éventuellement la chaîne soient éliminés.

Je confirme la gêne même si il n' y a pas de plaisir.
Ce traitement des guillemets est d' autant plus ennuyeux si l' on joue avec des chaines  pour d' autres langages.
Génération de code pour des pages html par exemple mais pas seulement.

Il est évident que je confirme cela, et pour cause.

Mais c'est pire que cela:

Code:

dim a$ : a$ = chr$(34)+"guillemet"+chr$(34):message str$(len("guillemet")) + chr$(13) + str$(len(a$))
end

On obtient le même résultat! Alors POURQUOI PROGRAMMER, SI LE PROGRAMME N'EST PAS RESPECTÉ!

Le pire pour moi est que Jack fait le mort lorsqu'on expose ces faits. Je sais qu'il est pris ailleurs, peut-être fait-il la guerre, je ne sais pas. Si il y a un problème avec le cœur de Panoramic pour rétablir ce fait, qu'il le dise, et on s'en excusera. Mais nous laissé sans réponse, même tardive, car on peut ne pas pouvoir le faire à des moments précis, c'est nous aussi nous sous-estimé. Je suis habitué de recevoir des coups, et de forcer les chose, donc il vaut mieux que ce sois moi qui le dise. Franchement alors qu'on défend Panoramic, on n'est pas entendu.

Maintenant moi je sors. J'ai pas de plaisirs à faire de la polémique.

Oui, c'est un vrai problème.

J'ai eu l'idée d'utiliser une procédure de JL35 pour crypter et décrypter un string, ce qui évite l'emploi de chr$(34)

ça peut toujours servir en attendant.

Code:

dim s$,a$,b$
edit 1
a$ = "abc"
Codec(a$) : a$=b$ : Codec(a$) : s$=b$
text 1,s$

END

SUB Codec(texte$)
b$ = "": DIM_LOCAL ic%: ' codage/décodage de texte$ -> retourne b$ par JL35
FOR ic% = 1 TO LEN(texte$)
b$=b$+CHR$(BIN_XOR(ASC(MID$(a$,ic%,1)),200-ic%*2))
NEXT ic%
END_SUB

A+

PS: Finalement je m'aperçois mon code ne sert à rien, mais c'est une piste

Code:

dim a$,b$,c$
a$ = "Le langage "
b$ = a$ +" PANORAMIC
c$ = b$ + " est formidable !
message c$
a$ = "Le langage
b$ = a$ + " PANORAMIC"
c$ = b$ + " est formidable !
c$ = c$ + " n'est-ce pas
c$ = c$ +" ?
message c$

Il y a des basics et autre langages qui emploi aussi l'apostrophe comme conteneur. Si il y a problème avec les guillemets avec le système Panoramic, peut-être que Jack pourrait ajouter cette possibilité. De toute façon ce sera encore une réclamation inutile.

Pour pouvoir lire un list qui a une chaine entourée de guillemet:
Ce qui ne marche pas:
a$ = item_read$(N,x) : if left$(a$,1) = chr$(34) then message "chaine avec guillemets"

Ce qui marche
if left$(item_read$(N,x),1) = chr$(34) then message "chaine avec guillemets"

Tant qu'on lit l'item d'un objet, on peut savoir si celle-ci est entouré de guillemets. On ne le voit pas, mais on trouve l'existance. Si c'est une variable, c'est reformaté sans ceux-ci.

C'est exactement ce que je dis, Cosmos70: c'est l'affectation à une variable (ou à un objet, ou l'utilisation dans la commande MESSAGE, etc) qui ne marche pas. Dès que les guillemets sont placées dans un objet (ou une variable) par un moyen quelconque, on peut lire et utiliser cela sans problème, mais on ne peut pas l'affecter à autre chose sans que le contenu soit altéré. Dans le cas d'une affectation à un objet ou l'utilisation de la commande MESSAGE, il y a certainement, de façon invisible, l'affectation à une variable temporaire, si bien que le cas est identique à l'affectation à une variable définie dans le programme. C'est certainement à ce niveau-là que Jack aura quelque chose à faire.

Je n'enlève rien à tes propos. Mais dans mon monde, j'ai rarement l'occasion d'entendre des grandes phrases et technique. Tout en comprenant de quoi tu parles, je finalise souvent très mal, d'autant je parcours bien trop rapidement la lecture d'un texte. Les exemples que j'ai mis, sont plus parlant pour moi.

Bonjour les panoramiciens,

Klaus a écrit:

Je n'ai pas voulu mettre cela dans les bugs

c'est clairement un bug de l'editeur:

Code:

dim s$,t$,lt

s$ = chr$(34)+"abc"+chr$(34)

t$ = chr$(33)+chr$(34)+"abc"+chr$(34) : lt=len(t$)

print s$
print right$(t$,lt)
print right$(t$,lt-1)

c' est comme si l'éditeur faisait: 'si le 1er caractère de la variable est un guillemet, alors c'est une chaine de caractère:supprime les guillemets'

C'est exactement ça, Silverman !

EDIT

D'ailleurs, ceci est possible:

Code:

print "abc
print "123"

La première ligne imprime le guillemet...
Il en est de même ici:

Code:

dim a$
a$ = "abc
print a$

Quelque part, ça a besoin d'être normalisé, tout ça !