	13 .	Conseils, ruses et problmes



	Conseils


Un programme V.A. bien crit, si le cahier des charges est fix, doit 
pratiquement donner le mme source, quel que soit le programmeur : a 
c'est l'effet OBJET.
Voici quelques conseils gnraux qui feront que votre programme res-
semblera  un source C dans le bon sens du terme, et sera donc lisible 
mais tout en restant performant !

. Le dilemme classique du programmeur est : je fais programme ra-
pide ou un source lisible ? Sachez qu'on ne peut avoir le beurre et 
l'argent du beurre, et il faut savoir sacrifier un peu de performance 
parfois, pour avoir un source maintenable. Exemple typique : 
remplacer un BSR label suivi d'un RTS par un BRA label. Je 
vous assure que la premire solution mme si elle est plus longue 
en source, plus longue en code gnr, plus longue enfin  l'ex-
cution est de loin la meilleure pour une relecture par une tierce 
personne ou aprs un temps long.

. Tout votre programme doit tre en USER, ainsi si l'utilisateur 
trouve une faille de votre programme, il fera deux bombes et ne 
plantera pas le systme pour peu que vous ne dtourniez pas de 
vecteurs. D'ailleurs, si on y rflchit bien, les routines SUPERVI-
SEUR peuvent et doivent se faire par le systme. En gnral, uni-
quement une routine ponctuelle trs particulire ncessite le mode 
SUPERVISEUR et s'appelle par SUPEXEC avec un passage de 
paramtres par BSS.

. Dans le cas de long traitements (recherche dans un fichier, sur les 
disques, etc), rendez-votre routine de traitement scable, de faon 
 la placer dans la routine EVNT_TIMER. Fixer le dlai du ti-
mer  1 milli-seconde pour ne pas perdre trop de temps. De cette 
faon, vous laissez la possibilit aux autres applications du syst-
me de fonctionner.

. Banissez de vos sources les labels sans signification comme :
		mauvais_exemple :	tst d0
					bne zap		; TEST OK
					cmp #1,d1
					ble.s .continue
Un bon nom de label vaut deux fois mieux qu'un label nul avec un 
commentaire en face.

. Si vous donnez des noms lisibles  vos labels et structures, alors 
votre source se passera presque de commentaires.

. Ne cdez pas  la tentation de faire un move #1,mon_objet sa-
chant que le champs que vous voulez remplir est  l'offset 0 de cet 
objet. Faites move #1,mon_objet+NB_SECTORS, cela vous vi-
tera un commentaire et de dsagrables surprises si la structure 
change un jour!

. Ne faites pas plusieurs sauts qui auraient des conditions diffren-
tes au mme label sinon vous prenez le risque de dplacer ce label 
malencontreusement et d'avoir oubli LA condition qui ne sup-
porte pas ce dplacement. De plus plusieurs labels explicitant bien 
leurs conditions respectives valent autant qu'un bon commentaire.

. Si un de vos BSS doit absolument tre  0 au dmarrage sous pei-
ne de gros disfonctionnement, alors mettez-le  zro mme si le 
systme est cens le faire, car en plus le fait de voir ce "clr.l add" 
au dbut vous rappellera qu'il est important !

. Optimisez votre code en place et en vitesse. Vous pouvez, par 
exemple, recopier plusieurs fois une instruction dans un DBF 
pour minimiser la perte de temps machine du DBF par rapport  
l'action dans la boucle (si elle est courte). Par contre, attention  
ne pas sortir du cache EXEC qui est de 256 octets par pages de 
16. Pour tre sur que votre boucle sensible en vitesse ne dpasse 
pas cette taille, limitez-vous, si vous pouvez,  des boucles d'au 
maximum 256-16*2 octets.

. Si vous avez besoin d'un timer utilisez le compteur 200Hz (des li-
brairies toutes faites existent) plutt que de dtourner des timers 
utiliss par le systme !

. Dcoupez votre source en plusieurs parties, a facilite la relecture.

. Attention en manipulant les ob_types : faites un and.w #$ff  cau-
se des objets de type tendu !

. N'hsitez pas  crer des structures de donnes pour vos BSS 
(fonction rs.x de DEVPAC 3.10) ; cela facilitera l'criture de vos 
programmes et les rendra plus lisibles.

Le TOS est bugg mais vous ne devez pas en tenir compte sauf pour 
ceux qui sont documents comme l'change des ports Midi et Srie avec 
Serial_test_buffer !
N'utilisez pas la routine DSP_sendblk car sur les machines rapides, 
comme l'change de donnes n'est synchronis qu'au dpart, si le DSP ou 
le 68030 sont boosts alors vous risquez la dsynchronisation. Ou bien 
utilisez et fournissez les patch existants.

	Ruses

. Si vous voyez mal les vnements qui arrivent sur vos objets de 
formulaires, ou sur vos fentres (et dans quel ordre ils arrivent) 
alors utilisez les labels OPT_DEBUG_VI-
SUAL_FORM_OBJ_EVNT & OPT_DEBUG_VI-
SUAL_WIND_OBJ_EVNT (cf. cration du fichier .DEF)

. Pour dtecter un systme multi-tche faites comme suit :
		cmp #1,global+_AESnumapps
		beq non_multitache

. Le numro de votre application (utile pour envoyer des messages 
par exemple) est dans :
		global+_AESapid..

. Ne faites pas un programme "bidouilleux", par contre n'hsitez 
pas  optimiser la structure mme du code : c'est diffrent.

. Pour namifier une fentre sans ascenseur autre que formulaire, in-
terceptez le message WM_FULLED + WM_BEFORE, testez les 
touches spciales et faites un
JSR GWVA_WIND_OBJ_PRG_NAMIFY_UNAMI-
FY_ONE_WIND
et hop ! le tour est jou.
Un exemple est donn dans VISUAL40\START\START.S pour 
les fentres bitmaps.

. vitez les ruses comme la peste : comme dit le proverbe :
	"Les ruses d'aujourd'hui sont les problmes de demain"

	Problmes

. Lorsque vous crez votre fentre, elle ne s'affiche pas :
- regardez le code d'erreur renvoy par le visual
- si c'est une fentre bitmap, la rsolution doit tre mauvaise

. vous n'tes pas prvenu d'un click sur un objet :
- votre objet est-il exit ou touch-exit dans votre ressource ?

. votre dbogueur plante de faon erratique  un endroit qui ne 
plantais pas avant :
- avez vous NVDI ? tss tss, enlevez le !

Le Visual AssembleurTM contient certainement des bugs (trs trs mi-
neurs car nous l'utilisons nous mme avec dlectation depuis 1 an sans 
problme) mais sera modifi grce  vos retours et finira par une version 
zro-bug ; alors faites-nous confiance !

