Viewer de Matrix|List - Page 1

voilà c'est fait !
voici la version C de mon viewer de LIST|MATRIX.
Une version existe déjà en Ti-Basic étendu grace à la Librairie Vertel.
J'ai fait cette version C, essentiellement pour gagner en vitesse.

Jeudi 19 Octobre 2005
mis-à-jour du lien
MATVIEW

merci a Vertyos pour Variable.

---

- Utilisation des 3 Font
- Titre Viewer
- Titre ligne
- Titre colonne
- recheche alphanumérique de la 1ere lettre par colonne
- Programme TI-Basic pour personnaliser l'édition des données

j'ai intégré le support de variable locale pour le programme 'callback'.
'callback' est le programme TI-basic qui se charge de l'édition lorsqu'on appuie sur [ENTER ] dans le viewer 'matview'.
Le prog 'callback' est recherché en priorité :
- dans le répertoire local
- ensuite dans le répertoire courant
- et pour finir dans le répertoire 'matview'

Ce qui vous laisse un maximum de souplesse pour personnaliser la façon dont vous voulez éditer vos données.



J'attend vos suggestions ou critiques

Tu devrais créer un compte sur Volume, pour 1° uploader le fichier en ton nom, et 2° éviter la limite de temps, il sera supprimé automatiquement dans une semaine là.

je vais le faire de ce pas
mais c'est pas sur que ce soit la version définitive.

[edit: cross, je parlais de ./2]


(non, rien ^^)

pour la garanti, c'est juste que j'ai oublier de mettre ça dans le Read-Me.
Cela ne doit en aucun cas vous effrayer.

Sinon y a pas de bug; du moins sur 92plus.

je pense que pour les autres aussi. en fait y juste les touches qui changent pour la 89

tiens, fonctionne pas ce lien

T'as pas du lire tout ce qui était marqué sur le site... T'as créé un compte mais pour le moment il est vide.

Si, j'ai tout lu. en fait j'avais fait une légère erreur lors de l'édition des données ( quand on appuie sur ENTER pour éditer, le 1er caractères est tronqué ).
j'ai corrigé tout ça donc je ferai l'upload définitive plus tard.
j'ai pris en charge la gestion en variable locale du programme 'callback'.

""

manque un s dans l'url

va falloir que tu revois ton générateur de Lien auto.
c'est que du copier coller.
c'est s à volume je suppose ?

tiens c'es files

nop à file

ok, j'espère que tu me diras, si c'est pas mal fait ce soft. bon ça fait presque 8Ko.
j'espère que mon lisez-moi est un minimum compréhensible

Euh, si des âmes généreuses pouvaient me donner des nouvelles des test sur Ti 89 et V200 ce serait sympa.
Je sais que ça intersse pas grand monde ce genre d'utilitaire ( car y a pas le pretty print ) et ...

Je l'ai testé sur ti89 Titanium. IL fonctionne
J'ai tester une grande matrice (15*20) et les dernieres lignes et colonnes sont coupées.

Ah enfin des nouvelles .
C'est bizarre comme bug surtout que je n'ai inclu aucune limitation.
je vais voir ça. Au début j'avais testé avec une Matrix 16*16 ; c'était impecable

Sinon j'ai une question sur un bug :
Quand un crash est intercepté par preos après l'exécution de la dernière ligne de code ( ce qui veut dire que tout le code est bien exécuté )
A quoi cela peut-il être du ?

Je viens de tester avec une Matrix 32*32.
Y a aucun affichage suite à une erreur géré en interne, en plus il y a perte de la mémoir allouée.

Je vais donc tracé ça pour détecté le bug.

Merci Saphari.

Bon, c'est pas fameux. je voulais utilisé la facilité en allouant un Tableau de string pour me macher le Travail, mais avec une énorme Matrix,
j'arrive à épuiser la RAM de la TI. d'où l'arrêt du programme.

C'est sur c'est plus simple à faire en procédant ainsi mais le résultat est pas fameux.

ça me fait chier d'utiliser un Tableau d'ESI pour stocker les pointeurs sur chaque élément de la MATRIX.

je vois d'ici ce que ça va demander comme boulot :
- que je sauve chaque élément de la Matrix comme une variable
Mince Alors

Moi qui me faisait une joie de laisser le TIOS faire le Salle Boulot.
C'est chiant mais quand faut y aller, faut y aller. Tant qu'à faire autant en faire un Bon

Si vous avez une meilleur idée pour la façon d'implémenter ça , je suis preneur.

./16 > Le bug peut être du à une corruption de la RAM de ta part, donc le système plante.

J'ai une TI89ti
c'est normal que pour se deplacer vers:
-le bas il faut appuyer sur la fléche de droite
-le haut il faut appuyer sur la fléche de gauche
-la droite il faut appuyer sur la fléche du bas
-la gauche il faut appuyer sur la fléche du haut

(c'est pas très pratique!)

En fait, c'est bien ce que je me dit aussi.
Mais les condition du bug reste un mystère pour moi.

Je charge avec le même code les paramètres du programme dans des variables Globales ( plus précisement des structures ).
le truc c'est que ça bug dans un seul cas de figure :
- pour un seul des paramètres, lorsque le nombre d'éléments est supérieur à 2

Bien sur les structures comportent des pointeurs pour allouer dynamiquement les LIST/MATRIX.

sasume ->

Le pire dans le bug que j'ai signalé c'est qu'il n'a lieu qu'une fois en tre chaque RESET de la TI . Après le 1er 'crash intercept' de Preos, le prog se comporte correctement. C'est à en perdre la raison.

Je vais pour la nième fois revoir le code. Ce qui m'énerve c'est que je sache exactement les conditions dans lesquelles ce bug se reproduit et que je n'arrivent pas à mettre la main dessus. je trouve ça vicieux comme bug

caamg -> je vais voir ça

Je me demande pourquoi Safari ne m'a pas signaler l'inversion des Touches
Si ça se trouve, la Titanium n'est pas détecté comme un TI89 ou alors j'ai fait une erreur. e SET_KEY_COL_SUB 45 #define SET_KEY_OFF KEY_ON #define SET_KEY_HELP KEY_APPS J'ai utilisé le code suivant pour définir les touches Clavier à la compilation : #ifndef USE_TI89 // Screen  for Ti 89 #define SCREEN_WIDTH 159 #define SCREEN_HEIGHT 99 - STATUS_LINE_HEIGHT - DISP_LINE_HEIGHT // Keys for Ti 89 #define MOVE_UP 337 #define MOVE_DOWN 340 #define MOVE_LEFT 338 #define MOVE_RIGHT 344 #define PAGE_UP 4433 #define PAGE_DOWN 4436 #define PAGE_LEFT 4434 #define PAGE_RIGHT 4440 #define PAGE_VTOP 16721 #define PAGE_VBOTTOM 16724 #define PAGE_HTOP 16722 #define PAGE_HBOTTOM 16728 #else // Screen  for Ti 92Plus, V200 #define SCREEN_WIDTH 239 #define SCREEN_HEIGHT 127 - STATUS_LINE_HEIGHT - DISP_LINE_HEIGHT // Keys for Ti 92Plus, V200 #define MOVE_UP 338 #define MOVE_DOWN 344 #define MOVE_LEFT 337 #define MOVE_RIGHT 340 #define PAGE_UP 4434 #define PAGE_DOWN 4440 #define PAGE_LEFT 4433 #define PAGE_RIGHT 4436 #define PAGE_VTOP 8530 #define PAGE_VBOTTOM 8536 #define PAGE_HTOP 8529 #define PAGE_HBOTTOM 8532 #endif // Common Keys #define SET_KEY_FONT_ADD 42 #define SET_KEY_FONT_SUB 47 #define SET_KEY_COL_ADD 43 #defin

Mince alors, je crois que j'ai oublié '#Define USE_TI89'.

j'ai un doute : dans la bôite 'Program Options' onglet 'Calcultor'
les 3 type de calc sont coché ce qui équivaut à créer 3 sources en utilisant la bonne constante pour chaque calculatrice


#define USE_TI89
#define USE_TI92PLUS
#define USE_V200

Tu utilises quoi pour tester les touches ?

Pour le bug, tu peux peut-être essayer avec la version modifiée par Flanker de PreOs, il donnera plus d'infos sur le bug.
Et sinon, essaie sans kernel pour voir de quel type de crash il s'agit (Illegal Instruction, Adress Error, Pretected Memory Violation, ...)

Bizarre, le bug du clavier.

> les 3 type de calc sont coché ce qui équivaut à créer 3 sources en utilisant la bonne constante pour chaque calculatrice
Oh que non, à moins que tu utilises l'horrible optimize calc constants, qui donne l'incompatibilité on-calc en un seul build, mais sans aucune optimisation faisable par le compilateur en temps de compilation. Le code étant plus mauvais, c'est à déconseiller.
Mettre les trois #defines ensemble, comme tu sembles l'avoir fait donne du code compatible on-calc, c'est à dire du code plus gros et plus lent, pénalisant tout le monde pour une minorité d'utilisateurs (92+/V200).
Plusieurs builds vraiment séparés (makefile ou deux TIGCC projects séparés - il est stupide dans la plupart des cas de faire du code incompatible entre 92+ et V200) ne sont pas la mer à boire.

Vous ne trouvez pas ça bizarre que je fasse ceci pour inclure le code à la compilation alors que dans la bôite de dialogue 'Program Options' onglet 'Calcultor' les 3 types de calc sont cochées

#ifndef USE_TI89
// Touche Ti89

#else

// Touche 92Plus, V200

#endif

Moi aussi ça m'a paru louche comme méthode. je pige pas pourquoi ça n'inclus pas le bon code

Normalement j'aurais dû faire

#ifdef USE_TI89
// Touche Ti89

#else

// Touche 92Plus, V200

#endif

Dans ce cas ce sont les touches de ma 92+ qui sont inversées

Lionel ->

je suis d'accord que c'est pas la mer à boire de faire comme tu as dis.
je vais donc faire 3 builds séparés pour voir ce que ça donne.

Sasume -> e );      return( keycode ); } voici comment je lis le clavier short waitKey( void ) {      short keycode;      do {           // Economie de batterie           idle();           // Lecture clavier           keycode = ( kbhit () ? ngetchx() : 0 );           if( !keycode || keycode == SET_KEY_OFF ) {                if( OSTimerExpired( APD_TIMER ) || keycode ) off();           }      } while( !keycod

En principe, parmi la boîte de dialogue options et les #define, c'est soit l'un, soit l'autre. N'as-tu pas des warnings ?

Les tests de touches bas niveau, comme les layouts de clavier sont très différents, gaspillent énormément de place.
Dommage que Ice Hockey 68k n'existe pas en version incompatible on-calc, en plus de la version compatible on-calc: le fait de ne sélectionner qu'un des modèles, sans rien faire d'autre, gagne déjà plus de 2 KB, si je me souviens bien.

J'ai pas eu de réponse au post 24


Lionel ->
Comme tu peux le voir, je n'ai pas de
#define USE_TI89
car je compte sur l'insertion automatique des options de compilation.

Je n'ai aucun Warning.

Tu penses que je devrais utiliser '_keytest' ( rowread ) pour lire le clavier au lieu de ngetchx() . M'enfin j'ai pas besoin de tant de vitesse que ça. j'ai essayé OSdequeue mais y pas la répétition de touches à condition de lire le bits masqué.
On fait comment pour ça ?

Hmm, j'ai fait un mélange de #21 et #24... Forcément, tu n'as aucun warning.

Ma remarque sur les tests de touches bas niveau était générale.

> j'ai essayé OSdequeue mais y pas la répétition de touches à condition de lire le bits masqué.
Il y a une faute dans la phrase, et je ne suis pas sûr de bien comprendre. Est-ce que tu veux tenir compte de la répétition des touches, ou est-ce que tu ne veux pas en tenir compte ?

Pour le ./25, ton code est idiot : les 3 symboles USE_TI89, USE_TI92PLUS et USE_V200 sont définis, donc ton test #ifdef USE_TI89 inclus forcément le code pour TI-89.
Il faut que tu ne définisses pas le symbole USE_TI89 pour qu'à la compilation le code pour TI-92+ soit inclus. Tu auras des binaires incompatibles, comme le souhaite Lionel.