indirection interne de vertel - Page 1

est ce qu'il est possible d'utiliser dans le même appel de vertel un élément d'une liste retournée de façon interne ds vertel ?

explications :

voilà ce que je suis obligé de faire:

vertel("e paus","/",
"e retr","/",
"v load","#@","/",
"v load","#@","/",
"v load","#@","/",
"v load","#@","/",
"v load","#@","/",
"v load","#@","/",
"v load","#@","/",
"e retr","/",
"v test",{344,338,13,340,337,264,265},"#@","/",
"e retr","k")

et ce que j'aurais voulu faire:

vertel("e paus","/",
"e retr","/",
"v test",{344,338,13,340,337,264,265},élément contenu ds var interne @,"/",
"e retr","k")

je n'ai pas tres bien compris comment marche ton 1er exemple, mais je crois avoir compris ce que tu veus faire : tu veux comparer le code de touche renvoyé par vertel à une liste et obtenir le n° de l'elt auquel il est egal
(pas mal comme methose, je n'y avait jamais pensé apres ca tu peux faire un goto #("key"&k) pour traiter les codes de touches (à moins que tu ne l'ai deja fait ) ca peut remplacer des if/elseif en chaine)
le 2eme bout de code ne marchera pas car "#(c)" (c'est le char (c) et non le char @ qu'il faut utiliser il ma semble) renvoit une liste et vertel compare les liste elt par elt et s'arrete quand il arrive à l'une des liste, or "#(c)" n'a qu'un seul elt (enfin ca tu l'as compris car tout en tapant ce' message j'ai eu l'illumination et j'ai compris à quoi servaient les v_load , enfin, flemme d'effacer )
tu peux faire sinon :

vertel("e paus","/", "e retr","k")
vertel("v_test",{344,338,13,340,337,264,265},k[1],"/","e retr","k")
comme ca tu auras bien une comparaison entre un nb et une liste et là plus de pb
ma methose prend moins de place et je pense qu'elle est plus rapode (bien qu'on ait 2 appels)

je crois avoir compris ce que tu veus faire : tu veux comparer le code de touche renvoyé par vertel à une liste et obtenir le n° de l'elt auquel il est egal

apres ca tu peux faire un goto #("key"&k) pour traiter les codes de touches (à moins que tu ne l'ai deja fait ) ca peut remplacer des if/elseif en chaine)

c bien ça
jvè faire comme t'as dit
Justement je doutais qu'augmenter une liste avec v load dans l'appel de vertel soit plus rapide que de faire deux appels.
Et comme j'suis un peu maniaque sur la vitesse donc que je voulais pas faire 2 appels g essayé des trucs comme ça:

vertel("e paus","/",
........."e retr","/",
........."v test",{344,338,13,340,337,264,265},"#c[1]","/",
........."e retr","k")

mais ça marche pas
tant pis

tu peux tester ce qui est le plus rapide
avec par exemple la fonction s_time de vertel (tu fais une boucle qui appelle plein de fois le bout de code et au final tu regarde cb de temps ca a mis)


mais pour le goto #("key"&k) je ne te garantis pas que ca soit tres rapide (cva sera surement moins rapide pour ce que tu aurais mis dans le 1er if et plus rapide que ce que tu as mis dans le dernier elsif, mais globalement je ne sais pas parceque les goto et indirections ne sont pas franchement rapides)

tu peux tester ce qui est le plus rapide avec par exemple la fonction s_time de vertel (tu fais une boucle qui appelle plein de fois le bout de code et au final tu regarde cb de temps ca a mis)

ouais g djà testé des code avec cette méthode (ça traçait même des graphes comparatifs ) mais g eu la flemme pour celui là...

mais globalement je ne sais pas parceque les goto et indirections ne sont pas franchement rapides

j'suis pas sur non plus que ce soit plus rapide que les IF ELSE ect ...
jvè faire le test par curiosité

sinon ya un truc que je trouve bizarre avec justement les goto #("key"&k) que j'utilise ds des menus ou des tableaux:

quand le tableau par exemple vient de se lancer il y a un temps d'adaptation (ds les quatres directions) pour que le passage d'une cellule à une autre devienne rapide
(mais c ptet un problème avec les fct° d'affichage de vertel aussi .... je sais pas)

un ralenti à chaque fois que tu vas dans une nouvelle direction ?
etrange ca...
je ne vois pas d'ou ca pourrait venir à moins que tu n'utilises des fonction créées avec un define
(dans ce cas, le ralentissement vient du fait que la fonction correspondant à une direction donnée est tokenizée, ce qui prend un peu de temps, avec d'etre executée. et comme la fonction n'est pas effacée, elle reste tokenisée et c'est pout ca qu'aux appels suivants il n'y a plus de ralentissement))

en fait pour me déplacer ds le tableau je fais varier deux variable globales i et j dans une boucle Lbl-Goto et pour que le déplacement soit rapide vers la droite par exemple il faut que je me soit déplacé environ 3 fois à droite avant ! (et j'utilise aucun Define)
j'vois vraimment pas d'ou ça peux vnir ...

mouais ca vient pas d'AMS alors je pense, c plutot ton code qui est "foireux"

sûrement

le problème c que je ne vois pas ou parce que i et j sont les seules variables qui peuvent être modifiées dans la boucle ...
(j'me demande si ça viendrait pas plutôt du k dans le Goto)

j'ai pas trop compris (essayé ? ) comment marchait ton prog donc je ne peux vraiment pas te dire ce qui est succeptible de poser pb (ouais en fait, j'ai pas du tout essayé de comprendre )

c normal j't'ai presque rien expliqué (toute façon ce serait trop long)
merci quand même d m'avoir répondu

vertel("e_paus","/","e_retr","/","v_test",{344,338,13,340,337,264,265},"#©","/","e_retr","k")
vala la ligne complète (normalement y a pas d'érreur)
Le v_load est ici pas utils, vu qu'il est implicitement appeller par e_paus (en fait, toute les fonction qui renvois une donnée font appelles à v_load). Tu peut aussi, par extension, fusionner plusieur renvois de variable à la suite.

Pour le ralentissement, g remarquer ça aussi quand g refait HexEdit. Je crois que ça vient de la fonction e_paus (j'en suis pas sur, ùais tant que j'utilisait getkey, j'av pas ce ralentissement).

Sinon, pas con le coup des goto #(key), je faudrat que je test ça dans HexEdit

vertel("e_paus","/","e_retr","/","v_test",{344,338,13,340,337,264,265},"#©","/","e_retr","k")

c bien ce que j'ai essayé de faire en premier lieu, mais comme © est une liste, vertel ne fait le test que pour 344 et "laisse tomber" le reste. c pour ça que j'ai essayé:

vertel("e_paus","/","e_retr","/","v_test",{344,338,13,340,337,264,265},"#©[1]","/","e_retr","k")

marci pour les infos sur le ralentissement :-)

bon, bah si, y av une erreur
Faut que je retrouve ma calc, que je test, voir si y a une solution meilleur que celle d'aze.

pour savoir si ca vient de e_paus, il faudrait attendre le retour du maitre des lieux

nan, il abandonne Vertel2 pour Vertel3

avec les pointeurs 4 etoiles ?

ué

j'en ai l'eau à la bouche

Y a même la gestions des listes en séquentiel ou parallel

mais il travaille vraiment dessus ou alors il a juste essayé ca pour le fun ?
(et l'imbrication des listes ?)
(et le croisage de listes ?)

Bah... je crois qu'il a vraiment bossé dessus. A priorie il a pas mal avancer pendant les vacances. Ca gère les listes de listes, on peut les utiliser séquentiellement ou parrallèlement. Je crois même qu'il a rajouté 2 argument à v_load pour remplacer left, right et mid (enfin, je lui av parlé d'un truc de ce genre et je crois bien que c ça, je suis plus trés sur).

il doit rentrer quand ?

2 septembre, si g bien suivit (dans 5 jours, koi).

je sens que jvè bien m'amuser avec vertel 3
(j'espère qu'elle permettra d'utiliser les éléments d'une liste en interne aussi )

Bon, bah en fait, va falloir attendre la rentré, j'av oublié que Vertel était inutilisable avec PedroM

c'est quoi PedroM