interface builder - Page 2

Cette feature aurait dû attendre le système d'exploitation où elle était à sa place: Windows 95.

Soit trois ans plus tard ? Sans avoir eu de retour du public ?
Hmmmm, vive l'évolution... Toi aussi, tu pense que 640ko de RAM ça suffit ?

D'ailleurs, tictex, qui n'utilise pas du tout une interface standard (F3 -> archive / désarchive ) est à proscrire pour cette raison

Bah oui... le seul explorateur standard c'est le Var-Link de toutes façons.

tiens je pensait justement a tictex

d'ailleur kevin a propos de gtk & qt, mais qu'elle horreur !! ce ne sont pas les standard Xwindow !!! il existe un librairie de widget fourni avec xwindow (et meme un window manager : twm !) ce sont eux les standard et surment pas KBEurk (j'ai installé recement la 3.2.1, ct lent, moche quasiment impersonalisable... et ça va vite virer)
d'ailleur les widgets fourni par la lib fourni avec xfree ressemble bcp au widgets d'ams

Nil
: Il y a des logiciels sous Windows qui utilisent GTK...

huhu, ça c'est vraiment un mauvais exemple parce que c'est hyper mal foutu (même si c mieux que pas de portage Win32 du tout, on est bien d'accord).

Il y a même des logiciels Microsoft (Office 97) qui surchargent les routines de Windows pour avoir ses propres routines (par exemple Word lancé sous Windows 3.51 aura quand même le look'n feel de 95).

Ca en revanche c pas une trop mauvaise idée, parce que ça reste au moins aussi utilisable, même si ça doit bouffer plus niveau RAM (d'ailleurs, pareil pour Office XP et VS.Net, qui utilisent des menus avec un look différent du natif)
Idem pour Firefox, qui utilise ses propres menus (cross-platform oblige, bien souvent) mais qui sont suffisamment bien foutus pour être agréables à utiliser (contrairement à GTK ou Java, qui sont déficients dans pas mal de domaines).

Pourquoi n'y aurait-il pas des logiciels sur TI qui utilisent un look'n feel personnalisé ? sincèrement, la taille des menus de la TI n'est pas la meilleure, il y a une perte énorme de place au niveau graphique... C'est pas parce que c'est TI qui l'a fait que ça doit devenir une obligation d'utiliser ça.

Sans compter la vitesse, sans compter le fait que faire une menu BW dans un jeu en gray c moche, sans compter le fait qu'on peut utiliser des touches plus adaptées à la position des touches dans le jeu (par exemple 2nd) ce qui évite de devoir changer de position de mains à chaque fois qu'on met sur pause ou qu'on perd une vie, sans compter que souvent refaire un menu ça prend 3x rien, etc...

Parce que ce sont des portages à partir d'un autre système d'exploitation (Linux) et que le programmeur n'a pas l'envie ou le temps de refaire toute l'interface. Mais c'est loin d'être idéal, on voit de loin que les programmes GTK ne sont pas à leur place sous Windows.

le problème c'est que GTK n'a pas été construit dans l'optique d'être multi-plateforme ce qui fait qu'en effet il n'est pas allaise sous Windows mais par exemple swing lui fonctionne bien.

Les features qui rendent l'interface de TI agréable à utiliser prennent de la place,

Oui et non. Le principal problème vient du fait que l'interface de TI est trop limitée.
Si TI avait fait un système plus flexible on aurait pas besoin de refaire les menus dès que l'on veut faire des fonctions un peu avancés ou qui permettent de mieu gerer l'espace écran.

Et parlant de perte de place, regarde-moi le menu popup personnalisé le plus utilisé (SMA et plein d'autres jeux): c'est un popup qui ne montre que 3 (!!!) entrées à la fois, avec en plus un défilé cyclique qui ne permet pas du tout de voir où commence et s'arrête le menu.

Je suis d'accord que c'est pas le menu le plus pratique mais pour un jeu il convient très bien, c'est sur que pour un shell c'est pas acceptable.

Non, c'est "--> Poubelle direct.".

Chut il va faire pression sur la TICT pour qu'il n'utilisent plus que les menu AMS dans la prochaine release

c'est cool je dois être mis en ignore par kevin il a pas du tout repondu à mon post

itu devrais pourtant savoir qu'il a une vision sélective des questions

Oui, il ne répond pas à toutes les remarques, mais c'est pas nouveau

oué d'ailleurs il a ommis pas mal de parties des posts qui ont suivis

Vark :
le manque de respect ...
dire à quelqu'un qui a pris du temps pour programmer qqch qui peut être utile à certains que son boulot c'est de la merde, qu'il peut le foutre à la poubelle c'est faire preuve de respect ?

C'est juste lui dire la vérité. La vérité peut être blessante parfois.

Nil
:

Cette feature aurait dû attendre le système d'exploitation où elle était à sa place: Windows 95.

Soit trois ans plus tard ? Sans avoir eu de retour du public ?

Pour les retours, il y a les bêta-tests. Le "retour du public" est vraiment une mauvaise justification pour mettre des contrôles inconsistents dans un système existant. S'ils sont mal reçus, ils le seront encore plus s'ils sont hors de leur place dans l'environnement visé.

Hmmmm, vive l'évolution... Toi aussi, tu pense que 640ko de RAM ça suffit ?

Non.

Godzil
: d'ailleur kevin a propos de gtk & qt, mais qu'elle horreur !! ce ne sont pas les standard Xwindow !!! il existe un librairie de widget fourni avec xwindow (et meme un window manager : twm !) ce sont eux les standard

Tu vas être content parce que je vais encore utiliser un de mes "mots préférés".
Les librairies dont tu parles sont obsolètes. Il suffit de regarder une distribution Linux moderne (Gentoo, Mandrake etc., tout sauf Debian stable ) pour t'en rendre compte.

et surment pas KBEurk

Troll...

(j'ai installé recement la 3.2.1, ct lent,

C'est rapide ici, et pourtant je n'ai que 128 MO de RAM (contre 192 MO "minimum" pour le mode graphique selon Red Hat). Réduis ton "eye candy" dans le KPersonalizer.

moche

Change de thème. Si tu n'aimes pas Keramik, il y a le thème classique, il y a aussi Bluecurve (packagé pour les distributions non-RH à plusieurs endroits) et plein d'autres.

quasiment impersonalisable...

KDE est nettement plus personnalisable que GNOME...

d'ailleur les widgets fourni par la lib fourni avec xfree ressemble bcp au widgets d'ams

Pollux
:

Pourquoi n'y aurait-il pas des logiciels sur TI qui utilisent un look'n feel personnalisé ? [...]

Sans compter la vitesse,

Tu crois que les menus en BASIC dont parle ce topic seront plus rapides?!

sans compter le fait que faire une menu BW dans un jeu en gray c moche,

On s'y habitue vite.

sans compter le fait qu'on peut utiliser des touches plus adaptées à la position des touches dans le jeu (par exemple 2nd) ce qui évite de devoir changer de position de mains à chaque fois qu'on met sur pause ou qu'on perd une vie,

Tu vois ça comme un avantage? Moi, je n'aime pas du tout les configurations de touches non-standard dans les menus.

Et d'ailleurs, dans certains cas (ça dépend du type de jeu), les jeux pourraient aussi permettre l'utilisation des touches standard dans le jeu lui-même. TI-Chess, par exemple, permet d'utiliser [ENTER] comme touche de confirmation dans tout le jeu. Dans Backgammon, je ne permets carrément que [ENTER] pour confirmer.

sans compter que souvent refaire un menu ça prend 3x rien

Refaire n'importe quel menu prend peut-être "3× rien" (et encore... tout ce qui prend plus de place qu'un appel au ROM_CALL correspondant est du gaspillage!). Refaire un menu à fonctionnalités équivalentes à celui de AMS et qui remplit les mêmes critères d'utilisabilité est déjà nettement plus difficile. Et les menus sont encore la partie "facile" de l'interface, avec les dialogues, les problèmes d'utilisabilité de la solution qui "prend 3× rien" sont encore plus évidents.

Uther
:

Parce que ce sont des portages à partir d'un autre système d'exploitation (Linux) et que le programmeur n'a pas l'envie ou le temps de refaire toute l'interface. Mais c'est loin d'être idéal, on voit de loin que les programmes GTK ne sont pas à leur place sous Windows.

le problème c'est que GTK n'a pas été construit dans l'optique d'être multi-plateforme ce qui fait qu'en effet il n'est pas allaise sous Windows mais par exemple swing lui fonctionne bien.

Tu trouves?! Je trouve GTK2/Win32 encore mieux que Swing/Win32... Et il n'y a vraiment aucune raison d'utiliser Swing quand il y a une alternative vraiment multi-plateforme (c'est-à-dire qui se base sur l'interface native de la plateforme): SWT!

Les features qui rendent l'interface de TI agréable à utiliser prennent de la place,

Oui et non. Le principal problème vient du fait que l'interface de TI est trop limitée.

En BASIC d'accord, mais on peut utiliser un programme C qui permet d'utiliser tout ce qui peut être utilisé en C/ASM, ça prendrait moins de place que Vertel + un programme BASIC pour l'interface.
En C/ASM, l'interface de TI passe très bien, son seul défaut est qu'elle ne marche qu'en blanc&noir.

Si TI avait fait un système plus flexible on aurait pas besoin de refaire les menus dès que l'on veut faire des fonctions un peu avancés ou qui permettent de mieu gerer l'espace écran.

Des fonctions "un peu avancés", il y en a assez. Tout ce qui est "plus avancé" ne fait que compliquer l'interface et irriter l'utilisateur.

Pour l'espace écran, tout coller en une fonte minuscule pour "mieux le gérer" n'est pas une solution, désolé. La meilleure solution est de couper ton dialogue surchargé qui ne rentre pas à l'écran en plusieurs.

Et parlant de perte de place, regarde-moi le menu popup personnalisé le plus utilisé (SMA et plein d'autres jeux): c'est un popup qui ne montre que 3 (!!!) entrées à la fois, avec en plus un défilé cyclique qui ne permet pas du tout de voir où commence et s'arrête le menu.

Je suis d'accord que c'est pas le menu le plus pratique mais pour un jeu il convient très bien,

Pas du tout!

c'est sur que pour un shell c'est pas acceptable.

Ce n'est pas acceptable tout court! Ça gaspille au moins 7/8 de l'écran et est vraiment tout sauf pratique à utiliser!

Vark
: c'est cool je dois être mis en ignore par kevin il a pas du tout repondu à mon post

J'ai répondu là.

Vark
: oué d'ailleurs il a ommis pas mal de parties des posts qui ont suivis

1. Je n'ai pas le temps de répondre à tout.
2. Il y a des messages auxquels il n'y a vraiment rien à répondre.

De toutes façons, les programmeurs sont libres de sortir ce qu'ils veulent na

C'est juste lui dire la vérité. La vérité peut être blessante parfois.

le "--> poubelle " n'est pas la vérité absolue c'est la vérité KK. C'est un inconvéniant certes mais pas un défaut rédibitoire comme tu voudrais le laisser penser. Beaucoup de programmes même ton cher TIChess utilisent des menus perso.

C'est rapide ici, et pourtant je n'ai que 128 MO de RAM (contre 192 MO "minimum" pour le mode graphique selon Red Hat). Réduis ton "eye candy" dans le KPersonalizer.

C'est quand même lent mais Gnome fait pâs mieux.

KDE est nettement plus personnalisable que GNOME...

Bah a ce niveau la je trouve qu'ils ce valent. personellement je ne trouve pas de grosse diférence entre KDE et gnome si ce n'est leur plotique qui me fait préferer GNOME.
Ca m'étonne pas que tu préfère KDE il te ressemblent pas mal. Tout en étant pour le libre , il applique les méthode microsoft.

On s'y habitue vite.

Bizarre. C'est pas toi qui dis d'habitude que c'est au programmeur et non a l'utilisateur de s'habituer sinon --> poubelle ?

Tu trouves?! Je trouve GTK2/Win32 encore mieux que Swing/Win32...

Swing a peut être ces défaut mais il tourne très bien. J'ai essayé le dernier Tilp sur windows/GTK c'est d'une lenteur et d'une incomodité flagrante. Je programme mon projet de stage avec SWING et en utilisant le L&F systeme ca passe totalement inapercu. Certes c'est plus lent que du MFC mais c'est vraiment multi-plateforme.

Et il n'y a vraiment aucune raison d'utiliser Swing quand il y a une alternative vraiment multi-plateforme (c'est-à-dire qui se base sur l'interface native de la plateforme): SWT!

SWT est contraire au principe du JAVA vu que justement il est dépendant de la plateforme native. SWING fait partie du JRE et il est donc est vraiment le standard.
Tu te contredis en plein la car tu préconise justement l'utilisation d'une interface non standard. --> poubelle

Des fonctions "un peu avancés", il y en a assez. Tout ce qui est "plus avancé" ne fait que compliquer l'interface et irriter l'utilisateur.

Au début quand j'ai fait TISH, j'utilisait les fonction AMS mais je me suis rendu compte que ca ne suffirait pas pour les listes. Si j'avais du essayer d'utiliser des moyen de me débrouiller avec les dialogue AMS, j'aurais du faire une interface plus complexe et au final pas plus économique en place
J'ai donc fait ma propre fonction de listes pour TIM qui finalement fera quasiment tout les affichages de TIM et donc sera bien plus économique en place que 50 menus AMS pas pratiques.

Pour l'espace écran, tout coller en une fonte minuscule pour "mieux le gérer" n'est pas une solution, désolé. La meilleure solution est de couper ton dialogue surchargé qui ne rentre pas à l'écran en plusieurs.

Un dialogue pas de problème ca ce coupe en plusieurs mais parfois ce n'est pas judicieux.

Kevin tu as raison, la vérité ça fait mal parfois

alors il va falloir que tu l'acceptes : ta VOLONTE n'est pas la VERITE de tout le monde

C'est juste lui dire la vérité. La vérité peut être blessante parfois

c'est TA vérité il y a des gens qui n'ont pas les mêmes gouts que toi ...

Refaire n'importe quel menu prend peut-être "3× rien" (et encore... tout ce qui prend plus de place qu'un appel au ROM_CALL correspondant est du gaspillage!). Refaire un menu à fonctionnalités équivalentes à celui de AMS et qui remplit les mêmes critères d'utilisabilité est déjà nettement plus difficile. Et les menus sont encore la partie "facile" de l'interface, avec les dialogues, les problèmes d'utilisabilité de la solution qui "prend 3× rien" sont encore plus évidents.

je préfère avoir de la place perdue pour des jolis menus que de la place perdue pour rien, comme c'est le cas dans un certain nombre de tes programmes. Tu devrais d'abord optimiser tes propres programmes en taille avant de critiquer les autres

Tu crois que les menus en BASIC dont parle ce topic seront plus rapides?!

en basic + flib, j'avais fait un dropdown plus rapide que celui de l'AMS

On s'y habitue vite.

on s'habitue vite à un truc moche, donc faut le garder ?

Pour l'espace écran, tout coller en une fonte minuscule pour "mieux le gérer" n'est pas une solution, désolé.

si c'est une solution !

Tout ce qui est "plus avancé" ne fait que compliquer l'interface et irriter l'utilisateur.

je ne vois pas le rapport

Kevin Kofler
:

Godzil
: d'ailleur kevin a propos de gtk & qt, mais qu'elle horreur !! ce ne sont pas les standard Xwindow !!! il existe un librairie de widget fourni avec xwindow (et meme un window manager : twm !) ce sont eux les standard

Tu vas être content parce que je vais encore utiliser un de mes "mots préférés".

Ya des fois ou tu arrives à me faire rire

Les librairies dont tu parles sont obsolètes. Il suffit de regarder une distribution Linux moderne (Gentoo, Mandrake etc., tout sauf Debian stable ) pour t'en rendre compte.

Pourtant c'est les widgets standard.. bcp d'appli les utilisent encore, et c'est sur de fonctionner avec un X11R5/R6 installé sans gd chose, et pi twm est tres puissant, si on sait le configurer

et surment pas KBEurk

Troll...

Ba oui, c'est pas trpo mon genre ^^

(j'ai installé recement la 3.2.1, ct lent,

C'est rapide ici, et pourtant je n'ai que 128 MO de RAM (contre 192 MO "minimum" pour le mode graphique selon Red Hat). Réduis ton "eye candy" dans le KPersonalizer.

Lent j'exagere un peu, enfin non pas a la compilation, pour compiler un KDE complet c'est au alentours de 116Mo, autent pour gnome. 10x plus de temps de compilation poru KDE
Pour ce qui est des effets.. J'ai tout les effet d'XP qui sont actif, ça me ralentit pas tout mon OS

sinon décidement j'aime pas konqueror.. Seul points fort actuellement pou kde : kbluetoothd, qui fonctionne a peut pret alors que les outils gnome pour le bt sont encore au stade de pre béta... mais bon il vont vite evoluer

moche

Change de thème. Si tu n'aimes pas Keramik, il y a le thème classique, il y a aussi Bluecurve (packagé pour les distributions non-RH à plusieurs endroits) et plein d'autres.

J'ai pas reussi a trouver un theme qu me confienne avec kde.. Gnome me parait bcp plus souple la dessus, rien que la possibilité (et ce simplement) de changer de window manager me plait bcp, kde est bcp plus chiant a config la dessus..

quasiment impersonalisable...

KDE est nettement plus personnalisable que GNOME...

Farfouille un peu plus gnome, le GUI est bcp plus personalisable qu'avec kde, ya ptet moins de choses en apparence avec gnome, mais celle-ci permettent généralement plus. Gnome est bcp plus bloatware que l'est kde

KDE sur bcp de points est surement mieux finalisé que l'est gnome oui, mais le code est mal maintenu et est bcp plus lourd. Gnome est léger, facile a configurer, kde est complet lourd et chiant a config.

d'ailleur les widgets fourni par la lib fourni avec xfree ressemble bcp au widgets d'ams

Je vais faire un screen de xman tiens juste pour rigoler ^^

Bon ça va les trolls?
On revient au sujet, pas d'autre avertissement.
Et Kevin, la prochaine fois ce genre de réflexion tu te les gardes.

Bon, je vais me limiter à une seule correction alors.
KDE permet aussi de changer de WM, il suffit de faire un killall kwin et puis d'en lancer un autre, et il s'en rappellera automatiquement. Mais Ximoon a raison, on est de loin hors-sujet là...

Sans commentaire.

Kevin Kofler
:

Sans compter la vitesse,

Tu crois que les menus en BASIC dont parle ce topic seront plus rapides?!

Je parlais des menus personnalisés en général, dont ton opinion n'est pas tellement meilleure que le cas particulier du premier post...

sans compter le fait que faire une menu BW dans un jeu en gray c moche,

On s'y habitue vite.

On s'habitue vite à utiliser une casio, donc il faut détruire les TI ?

sans compter le fait qu'on peut utiliser des touches plus adaptées à la position des touches dans le jeu (par exemple 2nd) ce qui évite de devoir changer de position de mains à chaque fois qu'on met sur pause ou qu'on perd une vie,

Tu vois ça comme un avantage? Moi, je n'aime pas du tout les configurations de touches non-standard dans les menus.

Ca dépend de ton jeu, mais pour un jeu qui utilise les flèches plus 2nd, c'est 1000x plus logique d'avoir 2nd pour valider que ENTER; finalement, ta critique porte plutôt sur le fait que c'est le jeu en lui-même qui est non-standard, parce qu'il devrait utiliser ENTER pour tirer ou sauter. Donc tous les jeux qui ne se jouent pas au tour par tour sont "non-standard"

Et d'ailleurs, dans certains cas (ça dépend du type de jeu), les jeux pourraient aussi permettre l'utilisation des touches standard dans le jeu lui-même. TI-Chess, par exemple, permet d'utiliser [ENTER] comme touche de confirmation dans tout le jeu. Dans Backgammon, je ne permets carrément que [ENTER] pour confirmer.

Et t'en es fier ? C'est pas parce qu'un truc est adapté à un type de jeu que c'est adapté à tous les jeux

Refaire n'importe quel menu prend peut-être "3× rien" (et encore... tout ce qui prend plus de place qu'un appel au ROM_CALL correspondant est du gaspillage!
).

Oui, absolument, d'ailleurs tu devrais militer pour supprimer ExtGraph pour que tous les jeux utilisent *enfin* la seule alternative supportée par la plate-forme : BitmapPut

Refaire un menu à fonctionnalités équivalentes à celui de AMS et qui remplit les mêmes critères d'utilisabilité est déjà nettement plus difficile. Et les menus sont encore la partie "facile" de l'interface, avec les dialogues, les problèmes d'utilisabilité de la solution qui "prend 3× rien" sont encore plus évidents.

Je veux bien t'accorder que dès qu'il y a une textbox, c'est difficile de faire aussi bien qu'AMS. Mais si tu n'en as pas besoin (comme dans un certain nb de cas), ce sera largement plus pratique de ne pas passer par AMS...

Les features qui rendent l'interface de TI agréable à utiliser prennent de la place,

Oui et non. Le principal problème vient du fait que l'interface de TI est trop limitée.

En BASIC d'accord, mais on peut utiliser un programme C qui permet d'utiliser tout ce qui peut être utilisé en C/ASM, ça prendrait moins de place que Vertel + un programme BASIC pour l'interface.

Et si le prog Basic en question utilise déjà Vertel ?

En C/ASM, l'interface de TI passe très bien, son seul défaut est qu'elle ne marche qu'en blanc&noir.

Ce n'est pas le seul, entre autre pour faire des trucs avec plein d'options à 2 ou 3 choix, c'est pas pratique du tout.

Si TI avait fait un système plus flexible on aurait pas besoin de refaire les menus dès que l'on veut faire des fonctions un peu avancés ou qui permettent de mieu gerer l'espace écran.

Des fonctions "un peu avancés", il y en a assez. Tout ce qui est "plus avancé" ne fait que compliquer l'interface et irriter l'utilisateur.

Ca n'irritera que Kevin Kofler, et comme de toute façon ça sera "poubelle direct", ce n'est pas un pb

j'essaierai de refaire le read-me pour qu'il soit plus clair; mais je pense qu'un screenshot animé sera plus parlant.
le hic c'est que je n'ai pas VTI surtout parceque je n'arrive pas à recuperer l'image de ma TI 92+
Toute bonne volonté voulant le faire sera la bienvenue !

Vertyos-> Il m'est arrivé d'avoir ‘internal error’ sur ma TI 92plus. Pourtant j’ai bien téléchargés la dernière version de VERTEL disponible sur ton site.
Cela arrive lorsque je fais ‘SAVE AS PRGM’ dans le menu FORM.
Le problème c’est que j’ai 2 variables locales m,n qui contiennent déjà des valeurs.
Ce que je fais sert à trouver la position de ‘ibuilder’ dans la liste des ‘Folder’ :
elvar m,n ou : 0 s-> m : 0->n
:main\vertel(″list″,″″, ″retr″,″m″,″″,″test″,″#m″,″ibuilder″,″″,″retr″,″n″)
C’est la que ça bug

Je tiens à situer de façon claire l'objet de ce programme :
Si vous avez déjà essayé de construire une interface graphique avec une librairie C pour le basic (en l'occurrence VERTEL ou FLIB) ; vous vous rendrez vite compte que toute décision de remodelage de l’interface, se transforme aussitôt en une séance de torture.
C’est de là que m’est venue l’idée de bâtir un utilitaire pour VERTEL.
Il servira peut-être de façon ponctuelle mais il contribuera efficacement à ce stade critique de la création de l’interface à laisser place à un peu de fantaisie !
C'est pas sensé remplacer le menu TI systématiquement !
C'est juste pour faire joli là où y en a besoin !

Hmm je n'arrive pas à reproduire ton bug, tu peux m'envoyer un programme court (pas plus de 10~15 lignes) qui le reproduise ?

Pour les Smiley dans le message c'est pas fait exprès.
J'ai fait du copier-coller depuis WORD
C'est pas évident, parceque ça n'arrive pas tout le temps.
je vais voir comment faire ça

andoh_wilfried :
j'essaierai de refaire le read-me pour qu'il soit plus clair; mais je pense qu'un screenshot animé sera plus parlant.
le hic c'est que je n'ai pas VTI surtout parceque je n'arrive pas à recuperer l'image de ma TI 92+ Toute bonne volonté voulant le faire sera la bienvenue !

Récupère la mise à jour de TI, VTI la comprend très bien!

Ok ! c'est bon VTI fonctionne mais je n'arrive ni à lui transmettre :
-le backup de ma 92+
-les fichiers individuels (backup dégroupé)
-rien, nada

Il met un truc du genre erreur de transfert.
Alors on fait comment ?

Quelqu'un aurait-il fait un InputString(x,y,STOvar,MaxLen,Width) en C que je puisse inclure dans le prog et qui supporte
- les variables locales
- le copier-coller
- le Var-Link
- le catalogue (facultatif)

Pour le Popup je vais faire appel à select de Vertyos.

Je pense qu'avec celà, je serai véritablement paré pour construire des "Interfaces Non Standard" en TI-basic.

J'ai déjà fait des InputString(x,y,STOvar,MaxLen,Width) en Vertel et en Basic ; mais ça manque de vitesse comparé à celui de TI.
Alors soyez gentils et fouiller dans vos archives !

Hmm nop, je me souviens qu'il y avait eu un concours du plus petit InputStr, mais il n'avait pas toutes ces fonctionnalités

en C / ASM, il faut créer une structure TE_Edit, ça doit pas être super super dur, juste un peu lourd à coder