cherche viewer - Page 2

fabetal
a écrit : erf, faut enregistrer sa V200 ? c bienh la première fois que j'entends parler de ça ... verrais ce w-e

fabetal
a écrit : stpatrick> tu peux me l'envoyer ? fabetal@orange.fr

ça amrchera pas le certif est lié avec le # de série de la machine...

guilc
a écrit : D'ailleur, j'ai quelques problemes pour l'exécution des programmes ASM archivés... Suivant la nature du programme, si il touche beaucoup a la mémoire, il peut y avoir plantage. J'ai du oublié de vérouiller un handle quelque part, mais je sais pas trop ou...

Tu parles du programme de comptabilité ?
Je me souviens, j'avais regardé les source, et il me semble que tu n'avais pas mis le #define SET_FILE_IN_USE_BIT alors que tu appelais des fonctions susceptibles de réorganiser la RAM (enfin, il me semble).
Mets-le et vérifie si ça plante tjs.
Sinon, l'erreur vient peut-être (même sûrement) d'un pointeur non valide après une réorganisation de la RAM. Donc soit tu vérouilles plein de handles, soit tu les recalcules tous à chaque fois que la RAM est susceptible d'avoir changée.

tiuser a écrit :
encore une question là sur ma calcu j'ai juste tictex et il tourne nickel alors est ce qu'il y aurait une utilité a mettre Preos.

Non.

jackiechan a écrit :
Tu parles du programme de comptabilité ? Je me souviens, j'avais regardé les source, et il me semble que tu n'avais pas mis le #define SET_FILE_IN_USE_BIT alors que tu appelais des fonctions susceptibles de réorganiser la RAM (enfin, il me semble).

Ce n'est pas la réorganisation de la RAM qui rend SET_FILE_IN_USE_BIT nécessaire, mais les appels directs ou indirects de la boucle d'évènements de AMS.

Et dans un explorateur de fichiers, il est conseillé de toujours utiliser SET_FILE_IN_USE_BIT, parce que le programme lancé pourrait utiliser la boucle d'évènements. Et en même temps, ça empêche aussi à l'utilisateur de lancer l'explorateur de manière récursive, ou pire de l'effacer en pleine utilisation. TICTEX faisait déjà quelque chose d'équivalent à SET_FILE_IN_USE_BIT bien avant l'introduction de cette directive.

Sinon, l'erreur vient peut-être (même sûrement) d'un pointeur non valide après une réorganisation de la RAM. Donc soit tu vérouilles plein de handles, soit tu les recalcules tous à chaque fois que la RAM est susceptible d'avoir changée.

Le ROM_CALL HeapShuffle (attention, il est très lent, surtout si tu l'appelles à plein d'endroits) peut aider à déboguer ce problème.

Ben si je rajoute SET_FILE_IN_USE_BIT, j'ai un beau illegal instruction...
Pour ce qui est de cacher le programme pour éviter une exécution récursive ou une suppression : le twin et le prog en archive sont cachés automatiquement durant l'exécution. C'était nécessaire pour empecher un bug lors de l'utilisation des boites de dialogue. Si j'ai bien compris, SET_FILE_IN_USE_BIT fait a peu près la meme chose ?

Il fait exactement ça, exactement pour la même raison. Mais ton "illegal instruction" me fait peur... Pourrais-tu mettre un breakpoint sur "illegal instruction" dans VTI (sous "breakpoint on trap/exception") et regarder dans quel contexte ça se produit. J'espère que ce n'est pas le code de SET_FILE_IN_USE_BIT qui est à l'origine du plantage.

En tout cas, SET_FILE_IN_USE_BIT marche chez moi. C'est probablement le fait que tu as essayer de cacher ton shell une deuxième fois en plus de SET_FILE_IN_USE_BIT qui fait tout boguer.

ftp83>Ca a l'air de marcher, d'après un mail reçu... De toutes façons, les apps peuvent être transmises d'une calculatrice à une autre du même modèle (je l'avais fait avec cellsheet)

En effet, ça marche, parce que le certificat est déjà préinstallé.