INPUT bug ou pas bug?

Bonsoir à tous les amis panoramiciens, Wink

Je voulais coder un petit programme d'essai utilisant l'instruction input et une chose bizarre m'est arrivée!!! Mad

Voyez plutôt le code suivant et rentrer une chaine de caractère après le point d'interrogation commençant par un chiffre, par exemple "4e". Après avoir validé la saisie avec la touche enter, vous aurez droit à: (52) Not correct string expression: Line:7

Code:: dim v$
v$="4e"
print v$
input_redo_on
input_visible_on
input_mark_on
input v$

terminate

J'ai même essayé en commençant la saisie avec la , le . le ; le ? le !
ainsi que les caractères accentués : à,ù,é,è,ê,ç
Je n'ai pas essayé tous les caractères...
Certains caractères m'ont mis l'erreur suivantes aussi: (52) Not correct string expression: Sequence Error, Bad Character. Line:7

Est-ce un bug où bien j'ai oublié de comprendre quelque chose? Question

Ai-je bu?

Merci de me répondre!

mëme si vous voulez entrer une chaine de caractère comme le mot "aujourd'hui" vous vous faites jeter à cause de l'apostrophe!
c'est pô juste!

Bon, je viens de résoudre mon problème avec les instructions "message_input ()" et message_text$.

Jack tu peux fermer le post.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Citation :: Jack tu peux fermer le post.

Pas vraiment car tu as découvert un véritable ~~bug~~ problème.

Je te remercie beaucoup Jack de prendre en considération ce bug, mais je me suis apperçu que l'on peut contourner le problème ou faire autrement avec un meilleur résultat en utilisant les fonctions précédemments cités dans mon dernier post ou en utilisant un edit. Il m'a suffit de faire une recherche à "input" sur le forum et de m'apercevoir que le problème ne date pas d'hier et avait déjà été soulevé depuis bien longtemps.
D'autant plus que cette instruction me parait maintenant obsolète vu tous les autres mots clés que possède Panoramic maintenant, et c'est bien le diable si on arrive pas à se débrouiller avec! Je considère que toutes difficultés ou bug peuvent être contournés d'une manière ou d'une autre.
Mais cela ne m'empêchera pas de te signaler tout bug que je croirais avoir mis au jour.
Encore merci Jack. A bientôt. Wink

Mais oui, mais même si tu peux faire mieux, Jack veut un Panoramic sans bug. Il va donc debugguer ce problème en priorité, c'est toujours comme ça qu'il procède Smile

Salut Jicehel,
Wink

Oui, mais n'empèche que je pense qu'il a d'autres instructions à faire et d'autres bugs plus important à corriger! Le post parlant du click droit de la souris est quand même plus prioritaire que le input, même si Jack place tous les bugs au même niveau pour avoir un langage irréprochable. Maintenant, c'est mon point de vue et il n'engage que moi.
J'ai relevé un bug, je lui ai signalé et c'est le minimum que je puisse faire pour lui en retour de tout ce qu'il a créé et qu'il va encore créé avec les autres langages comme goric, sputnic etc... pour nous et notre plaisir de programmer.

Bon boulot Bignono Smile

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

Je suis bien persuadé que Jack considère, avec raison, que la correction des bugs est prioritaire par rapport aux nouvelles fonctionnalités, quitte à respecter une hiérarchie dans les bugs.

Et qu'il ne faut pas hésiter à signaler les bugs, quels qu'ils soient, à Jack de juger de leur importance ou priorité, pour moi ça va sans dire, mais comme dit l'autre ça va mieux en le disant.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Je voudrais tempérer un peu ce que je disais en parlant de "bug".
Ce problème existe depuis les premiers temps de PANORAMIC.

Lorsque je regarde la "spécification" de l'instruction INPUT (que j'ai écrite en mi-2005), je m'aperçois qu'elle est exactement comme celle de l'instruction DATA en ce qui concerne les chaînes de caractères: il faut mettre des guillemets en cas d'ambiguité.

Par exemple:

Code:: data abc, "4e", zarty, "la maison", "l' approche", abcd
dim i%,v$
for i%=1 to 6
read v$:print v$
next i%

donne:

Code:: abc
4e
zarty
la maison
l' approche
abcd

D'ailleurs dans ton exemple, pour le INPUT V$, si tu tapes "4e" (avec les guillemets) au lieu de 4e (sans les guillemets), ça fonctionne:

Code:: dim v$
v$="4e"
print v$
input_redo_on
input_visible_on
input_mark_on
input v$
terminate

Il en est ainsi pour tout traitement des chaînes de caractères:

Code:: button 1:caption 1,bouton

est accepté

Code:: button 1:caption 1,le bouton

n'est pas accepté

Code:: button 1:caption 1,"le bouton"

est accepté
Il me semble qu'en Basic, on ne met des guillemets que s'il y a risque d'ambiguité (par exemple pour prendre en compte un espace ou un caractère particulier dans une chaine, et on ne met rien quand tous les caractères sont accolés.

Mais existe-t-il quelque part une définition du Basic, une norme qui précise cela ?

Bonjour Jack, Very Happy

Je viens de me connecter et de lire ta réponse. Effectivement j'avais compris que mettre un guillemet, résolvait le problème.
Par contre, je ne sais pas si c'est possible pour résoudre ce bug, (je m'avance peut-être trop vite car je ne suis pas spécialiste en la matière), ce serait que chaque fois qu'on a une chaine de caractère à rentrer avec l'instruction input (n)$, le guillemet soit affiché d'office. Ou alors qu'il soit programmé à la base et n'apparaisse pas lors de la saisie. Je ne sais pas si tu comprends ce que je veux dire.
Bon, un grand merci quand même! Wink

l'utilisation des guillemets sur une chaîne de caractères associées à une variable "x$" est, je pense, la règle pour tout les basics.

C'est pourquoi je pense qu'on n'a pas vraiment affaire à un bug.
A mon sens le bug serait plutôt d’accepter button 1:caption 1,bouton

Personnellement j'écris toujours button 1:caption 1,"bouton", par habitude.

Mais finalement c'est peut-être bien comme çà.

A+

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

Tiens, finalement moi aussi je mets systématiquement et machinalement des guillemets pour un caption, un nom de fichier dans un File_Load, etc., je ne m'étais jamais posé de question là-dessus, ça me paraît naturel, ce sont des strings.

Bonsoir,

Aussi loin que je me souvienne, une chaine de caractère est toujours délimitée par des guillemets (basic sur MO5, ORIC1,C64,etc...)

Si on écrit :
BOUTON 1:CAPTION 1,ESSAI

1-Au niveau sémantique cela signifie: dans caption 1 je met le contenu de la variable ESSAI
2- Je devrais avoir une erreur de syntaxe car obligatoirement dans un caption c'est obligatoirement une variable de type texte donc avec $

Ce problème existe aussi avec ITEM_ADD, je n'ai pas d'erreur si j'écris:
ITEM_ADD 2,135
Alors que normalement je devrais écrire : ITEM_ADD 2,STR$(135)
Comme le dis Jack, c'est le même phénomène avec l'instruction DATA...

Bien sur que je sais que pour toutes chaines de caractères ou string, il faut utiliser les guillemets. Mais moi, ce que j'ai à l'esprit avec l'instruction INPUT v$,
c"est qu'en cas de rentrée d'un string commençant par un chiffre ou d'autres caractères spéciaux, cela ne devrait pas bugger et être accepté.
Je me met à la place de l'utilisateur d'un éventuel logiciel fait en Panoramic. Lui, il ne sait pas qu'il faut rentrer un guillemet avant de taper le chiffre ou un autre caractère spécial. Le input génère l'erreur même avec le ç ou le é! Même si on avise l'utilisateur final que pour entrer le mot épée il faut le mettre entre guillemet, il trouvera ça trop lourd au final et se détournera du programme.
Et c'est bien là qu'est tout le problème! Wink

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

Là-dessus, pour un input, tu as parfaitement raison, l'utilisateur n'a pas à s'occuper des guillemets, c'est un truc de programmeur !

Pour l'input, je suis d'accord !
Dans le cas où la variable est de type chaine, les guillemets sont implicites. Wink

il me semble que l'on a déjà parlé de ce sujet... Wink

Salut à tous

Perso je me pose 2 des questions:

1) Ne devrait-il pas y avoir 2 commandes input: INPUT$ pour les string et INPUT pour les variable numériques

2) Il existe 2 fonctions MESSAGE_INPUT dont une MESSAGE_INPUT$, au début j'ai cru, à tord, que c'était pour différencier le type de variable saisie par l'utilisateur, en fait la différence entre les 2 c'est l'indication (ou pas) de quel bouton a été cliqué

Me demandez pas de réponses car j'en suis incapable.

A+

Bonjour à tous les amis de Panoramic Very Happy

Le sujet de input vous en avez déjà parlé par le passé. Mais à travers input, moi ce qui me gène, c'est l'utilisation des string.
Au travers du petit prog ci-joint, je ne saurais que recommander la plus grande prudence avec la manipulation des chaines de caractère, surtout si vous voulez les concaténer avec l'opérateur +.
Le post de Nardo sur le guillemet diabolique met bien en évidence la problématique des strings! Dans le second code que je joint, dans le même post du guillemet diabolique, Klaus nous donne un exemple de comment panoramic interprète la chaine de caractère avec chr$(0) caractère nul. Ce chr$(0)
est pourtant interpréter comme un caractère espace alors qu'il est normalement nul et indique la fin de string!
L'instruction len(v$) le démontre bien.
Peut-être que quelqu'un peut donner une explication plus approfondie à ce phénomène?

Moi, en attendant, ce que je dis, méfions nous de la manière dont nous traitons les chaines de caractère car les résultats sont parfois inattendus. D'autant plus que d'après ce que j'ai lu, le langage C et Delphi interprète différement les strings.
code 1:

Code:: width 0,400:height 0,700
dim v$:v$="épée":print v$:print
input_redo_on:input_visible_on:input_mark_on

input v$: ' <=== tapez la séquence: "épée"
print v$: ' <=== résultat: épée
print len(v$):print: ' <=== résultat: 4

input v$: ' <=== tapez la séquence: "épée
print v$: ' <=== résultat: "épée
print len(v$):print: ' <=== résultat: 5

input v$: ' <=== maintenant tapez le caractère: +
print v$: ' <=== résultat: +
print len(v$):print: ' <=== résultat: 1

rem input v$: ' <=== maintenant tapez les caractères: ++
' <=== résultat: Vous partez en erreur!!!

input v$: ' <=== tapez la séquence: "épée"+"épée"
print v$: ' <=== résultat: épéeépée
print len(v$):print: ' <=== résultat: 8

input v$: ' <=== tapez la séquence: "épée"+"épée
print v$: ' <=== résultat: épée"épée
print len(v$):print: ' <=== résultat: 9

input v$: ' <=== tapez la séquence: chr$(34)
print v$: ' <=== résultat: "
print len(v$):print: ' <=== résultat: 1

input v$: ' <=== tapez la séquence: chr$(34)+chr$(34)
print v$: ' <=== résultat:
print len(v$):print: ' <=== résultat: 0

input v$: ' <=== tapez la séquence: chr$(34)+"épée"+chr$(34)
print v$: ' <=== résultat: épée
print len(v$):print: ' <=== résultat: 4

input v$: ' <=== tapez la séquence: chr$(34)+"épée
print v$: ' <=== résultat: ""épée
print len(v$):print: ' <=== résultat: 6

input v$: ' <=== tapez la séquence: chr$(34)+chr$(34)+"épée"+chr$(34)+chr$(34)
print v$: ' <=== résultat: épée
print len(v$):print: ' <=== résultat: 4

code2:

Code:: ' Ici les exemples de Klaus dans le post de Nardo sur le guillemet diabolique
' Le chr$(0) est compté dans len(a$), alors qu'il ne devrait pas l'être
dim a$
a$=chr$(34)+"essai"+chr$(34)+chr$(0)
print a$: ' <=== résultat: "essai" (7 caractères)
print len(a$): ' <=== résultat: 8

a$=chr$(0)+chr$(34)+"essai"+chr$(34)
print a$: ' <=== résultat: "essai" (7 caractères)
print len(a$): ' <=== résultat: 8

Cordialement Smile

La démonstration est très clair,

Moralité il faut bien utiliser les guillemets même si Panoramic ne dit rien. Et qui sait, un jour on pourrait se retrouver à revoir nos programmes.

A+

Et voilà, je viens de réaliser comment fonctionne l'instruction input v$.
exactement comme si vous écrivez dans le programme V$="essai". Si vous faites V$=essai (sans les guillemets) print V$ donera --> essai.
C'est ce qui se passe avec input V$. Vous rentrez une chaine de caractères sans espace et sans caractères spéciaux, vous n'avez pas d'erreur!
Si vous faites V$=un essai (sans les guillemets) vous partez direct en erreur. La même chose avec input V$ car vous avez introduit un espace dans le string!
Normalement à la commande input V$, le guillemet devrait être implicite comme disait Nardo plus haut, et aussi implicite dès que l'on appuie sur la touche enter. Le bug il est là!

OK, pour moi le bug c'est que l'on devrait être obligé de mettre les guillemets (sinon message d'erreur).

Je pense que ne pas mettre les guillemets sous prétexte que Panoramic ne relève pas, ce n'est pas de la bonne programmation et surtout, à la fin on se perdra pour savoir si on a mis (ou pas) des caractères spéciaux ou des espaces dans notre string.
Et je le répète, si un jour Panoramic n'accepte plus les strings sans les guillemets, je t'explique pas pour les programmes anciens ce qui risque d'arriver. Bon, je sais que Jack ferait (dans le cas) tout pour éviter ce problème.

Pour moi, je pense avoir fait le tour du sujet.

A+

Jean-Claude

Je suis d"accord avec toi, mais il faut se mettre à la place de l'utilisateur du programme et pas du programmeur. Je vais me citer:

Citation :: Je me met à la place de l'utilisateur d'un éventuel logiciel fait en Panoramic. Lui, il ne sait pas qu'il faut rentrer un guillemet avant de taper le chiffre ou un autre caractère spécial. Le input génère l'erreur même avec le ç ou le é! Même si on avise l'utilisateur final que pour entrer le mot épée il faut le mettre entre guillemet, il trouvera ça trop lourd au final et se détournera du programme

C'est ce problème que je met en évidence avec ce bug! Et ici il s'agit de ne pas mettre les guillemets que juste pour l'instruction input V$.

Tu as raison, il faut toujours se mettre à la place de l'utilisateur.

Aussi regarde cette exrait de code:

Code:: montant:
m=message_input("Changement du montant", "Nouveau Montant" , mt$)
if m=0 then return
a$=message_text$:if numeric(a$)=0 then message "Valeur numérique uniquement":goto montant
a=val(a$):nba=22:vg$="":sg$=" ":gosub string_montant:mt$=a$
return

C'est au programmeur de prévoir les erreurs de l'utilisateur. Dans le cas ci-dessus l'utilisateur est averti qu'il doit entrer des chiffres par if numeric(a$)=0 then message "Valeur numérique uniquement".
C'est pourquoi je pense qu'il manque la commande INPUT$ et que INPUT ne devrait accepter que des valeurs numériques.

T'inquiète pas Jack trouvera une solution.

A+

Bonjour,

Au sujet de "INPUT" / "INPUT$"

pour moi c'est la même chose que:
INPUT nombre% / INPUT chaine$

Le type de la variable passée en paramètre suffit amplement :
Si on ne tiens pas compte du type de la variable passée en paramètre à la commande INPUT, à quoi sert dans ce cas la fonction STR$() ? A rien ? Dans quel cas doit-on l'utiliser alors ?

Je me répète peut être, mais pour STR$() c'est déjà + ou - le cas:
ITEM_ADD 2,123 ou ITEM_ADD 2,"123" ou ITEM_ADD 2,STR$(123) font exactement la même chose... Smile

Il y a vraiment quelque chose à revoir sur la façon dont sont identifiées (mémorisées) les variables de type chaine$. Il n'y a qu'a voir sur les forums de delphi, le nb de problèmes rencontrés dès qu'on touche à une chaine de caractère (et le nb de déclaration de variable de type chaine ! c'est un vrai merdier ! Very Happy

)

Je pense que ce qui retient Jack et qui fait que cela n'est pas si évident que ça, c'est de maintenir une compatibilité avec les anciens programmes (notamment à cause de DATA...) et puis revoir l'expression régulière qu'il doit y avoir derrière cela ne doit pas être facile...

» INPUT
» INPUT et LPRINT
» Mots clés obsolète.
» remplacement de INPUT
» GROS PROBLEME AVEC INPUT