repertoire 0001 - Page 2

Kevin Kofler a écrit :
Le fait qu'il affiche les répertoires temporaires est un bogue de TxtRider.

Je veux bien que ce soit un bug, mais il est évitable si on ne créé pas de variable locale dans le prog basic qui lance txtrider normalement.
En tout cas ça marche avec fileedit.

D'ailleurs, ce bogue est dû au fait que ces programmes n'utilisent pas les ROM_CALLs de vat.h, mais préfèrent aller traffiquer dans la VAT eux-mêmes. Donc programmeurs, écoutez mon conseil: Ne touchez pas à la VAT, utilisez les ROM_CALLs qui le font pour vous!

C 100x plus rapide de faire ses propres routines qi lisent les fichier que d'utiliser les ROMCALL qui n'on été fait que pour les apps "lente" et au TIBasic....

Sinon pour les rep 000x il suffirait au programmeur de pas etre trop c*n et de pas afficher tt les rep qui commence par un chiffre pour la simple et bonne raison que on ne peut pas en creer normalement avec la TI !

godzil
a écrit : C 100x plus rapide de faire ses propres routines qi lisent les fichier que d'utiliser les ROMCALL qui n'on été fait que pour les apps "lente" et au TIBasic....

Mais ça gaspille de la place! (Et ne me raconte pas des leçons sur les librairies dynamiques: la place est inévitablement gaspillée parce que la routine est déjà dans la ROM! Même si la routine réécrite n'est présente qu'une fois!)

si on veut un truc lent ou pas bo et qui prend pas de place on utilise le var-link

lol

Pour plus de compatibilité et moins d'erreurs, je conseille aussi vat.h, c'est plus simple, pas à se creuser la tête à chercher la ligne qu'on a oublié...

[cite]Kevin Kofler a écrit :
Mais ça gaspille de la place !cite]

Tu te démerdes pour foutre 5 fois ton h220xtsr sur la calc, et tu parles de place gaspillée ??

Kevin mérite des baffes.

MacIntoc >> Sinon, y a Einstein qui as ce bug, aussi

Ce n'est pas un bug les fichiers cachés n'apparaîtront plus dans la ß3.0.

Titane a écrit :
Tu te démerdes pour foutre 5 fois ton h220xtsr sur la calc, et tu parles de place gaspillée ??

Il y a une différence entre "place gaspillée" et "place utilisée". Je considère que le fait d'intégrer h220xTSR aux TSRs est de la place utilisée (parce que ça rajoute une fonctionnalité, la compatibilité avec HW2 AMS 2), pas de la place gaspillée.

Oui, mais ce ne serait pas possible de demander à dans le readme l'utilisateur d'installer h220xTSR avant d'installer tes autres TSRs, comme ça tu ne le mets pas dans chaque TSR.
Ou bien tu fais 2 versions (une qui contient h220xTSR, une sans)

jackiechan
a écrit : Oui, mais ce ne serait pas possible de demander à dans le readme l'utilisateur d'installer h220xTSR avant d'installer tes autres TSRs, comme ça tu ne le mets pas dans chaque TSR.

Non! Je ne veux pas que h220xTSR devienne une sorte de kernel, c'est pour ça que je l'ai intégré aux TSRs. Je veux que mes TSRs soient le plus simples possible à installer pour l'utilisateur, et il est hors de question de demander l'installation manuelle préalable de h220xTSR.

Ou bien tu fais 2 versions (une qui contient h220xTSR, une sans)

Non. Je ne vois pas l'intérêt, vu que la version qui le contient fonctionne très bien même s'il est déjà installé.
Et puis il n'y a pas que mes TSRs à moi à intégrer h220xTSR.

Le pb, c'est quon le copie 5 fois alors qu'une seule suffirait.
Il fait quelle taille ?

1445 octets.
Bon, ça va, ce n'est pas trop...
Mais quand même.

jackiechan a écrit :
1445 octets. Bon, ça va, ce n'est pas trop...

En effet, c'est ce que je me dis aussi. Je ne vais pas m'amuser à distribuer plusieurs versions de mes TSRs pour ça.

ca repond pas au topic : rep 0001 comment le faire disparaitre.....

tu peux pas apparement... ou bien évite de lancer le prog (je c plus ce que c'est) depuis un lanceur basic

y a kkchose de plus simple, tu ignore ce dossier

igonoer c'est facile

Scherubin a écrit :
il est évitable si on ne créé pas de variable locale dans le prog basic qui lance txtrider normalement. En tout cas ça marche avec fileedit.