From: Jacob Wall on 31 Jul 2010 22:10 Hello all, Not sure if I'm missing something obvious or if there's another less known bug in IfMain. First some sample code: :: "LABEL:" BINT0 BINT10 "LABEL:" BINT0 BINT19 ' :: BINT0 #=case :: OVER BINT7 #=case :: 2DROP "Key Assigned!" FlashMsg TRUE ; FALSE ; FALSE ; BINT28 BINT9 BINT103 BINT8 BINT1 { BINT0 } BINT2 NULL$ MINUSONE DUP %0 DUP 'DROPFALSE BINT28 BINT18 BINT103 BINT8 BINT1 { BINT0 } BINT2 NULL$ MINUSONE DUP %0 DUP BINT2 BINT2 'DROPFALSE "TEST FORM" FPTR 4 20 ; Simple input form, two labels, two fields. The first field has a key message handler, no message handler for the second field. Some observations I've boiled down from a lot of testing: 1. Run sample input form, first field is current, press the APPS key (#7), the "Key Assigned!" message flashes, press the key again and again, repeats as expected. 2. Run sample input form, press any key other than #7, normal behaviour as expected, keep pressing random keys other than #7, no problems. 3. Run sample input form, press TOOL, MODE, HIST, or even the EDIT(followed by CANCL) key, then press #7, no problem. 4. Run sample input form, press NXT, VAR, LeftSHIFT, RightSHIFT or Alpha key first, then press #7, CRASH! It appears that pressing a key which doesn't result in a direct action being taken, is not a problem if it is pressed prior to the key that is defined. If some sort of action is performed immediately before pressing an assigned key, and the field with the key message handler remains the one with the focus, then the next assigned key press triggers a crash for reasons not yet known. Can anyone spot an error or omission I've made, or know of a workaround? -- Jacob Wall
From: Jacob Wall on 31 Jul 2010 22:17 Forgot to add: WARNING WARNING WARNING The code in previous post can result in a memory loss, backup your data before testing. -- Jacob Wall On 31/07/2010 7:10 PM, Jacob Wall wrote: > Hello all, > > Not sure if I'm missing something obvious or if there's another less > known bug in IfMain. > > First some sample code: > > :: > "LABEL:" > BINT0 > BINT10 > "LABEL:" > BINT0 > BINT19 > ' > :: > BINT0 > #=case > :: > OVER > BINT7 > #=case > :: > 2DROP > "Key Assigned!" > FlashMsg > TRUE > ; > FALSE > ; > FALSE > ; > BINT28 > BINT9 > BINT103 > BINT8 > BINT1 > { > BINT0 > } > BINT2 > NULL$ > MINUSONE > DUP > %0 > DUP > 'DROPFALSE > BINT28 > BINT18 > BINT103 > BINT8 > BINT1 > { > BINT0 > } > BINT2 > NULL$ > MINUSONE > DUP > %0 > DUP > BINT2 > BINT2 > 'DROPFALSE > "TEST FORM" > FPTR 4 20 > ; > > Simple input form, two labels, two fields. The first field has a key > message handler, no message handler for the second field. Some > observations I've boiled down from a lot of testing: > > 1. Run sample input form, first field is current, press the APPS key > (#7), the "Key Assigned!" message flashes, press the key again and > again, repeats as expected. > 2. Run sample input form, press any key other than #7, normal behaviour > as expected, keep pressing random keys other than #7, no problems. > 3. Run sample input form, press TOOL, MODE, HIST, or even the > EDIT(followed by CANCL) key, then press #7, no problem. > 4. Run sample input form, press NXT, VAR, LeftSHIFT, RightSHIFT or Alpha > key first, then press #7, CRASH! > > It appears that pressing a key which doesn't result in a direct action > being taken, is not a problem if it is pressed prior to the key that is > defined. If some sort of action is performed immediately before pressing > an assigned key, and the field with the key message handler remains the > one with the focus, then the next assigned key press triggers a crash > for reasons not yet known. > > Can anyone spot an error or omission I've made, or know of a workaround? > > > -- > Jacob Wall
From: Han on 31 Jul 2010 23:27 On Jul 31, 9:10 pm, Jacob Wall <jac...(a)surv50.ca> wrote: > Hello all, > > Not sure if I'm missing something obvious or if there's another less > known bug in IfMain. > > First some sample code: > > :: > "LABEL:" > BINT0 > BINT10 > "LABEL:" > BINT0 > BINT19 > ' > :: > BINT0 > #=case > :: > OVER > BINT7 > #=case > :: > 2DROP > "Key Assigned!" > FlashMsg > TRUE > ; > FALSE > ; > FALSE > ; > BINT28 > BINT9 > BINT103 > BINT8 > BINT1 > { > BINT0 > } > BINT2 > NULL$ > MINUSONE > DUP > %0 > DUP > 'DROPFALSE > BINT28 > BINT18 > BINT103 > BINT8 > BINT1 > { > BINT0 > } > BINT2 > NULL$ > MINUSONE > DUP > %0 > DUP > BINT2 > BINT2 > 'DROPFALSE > "TEST FORM" > FPTR 4 20 > ; > > Simple input form, two labels, two fields. The first field has a key > message handler, no message handler for the second field. Some > observations I've boiled down from a lot of testing: > > 1. Run sample input form, first field is current, press the APPS key > (#7), the "Key Assigned!" message flashes, press the key again and > again, repeats as expected. > 2. Run sample input form, press any key other than #7, normal behaviour > as expected, keep pressing random keys other than #7, no problems. > 3. Run sample input form, press TOOL, MODE, HIST, or even the > EDIT(followed by CANCL) key, then press #7, no problem. > 4. Run sample input form, press NXT, VAR, LeftSHIFT, RightSHIFT or Alpha > key first, then press #7, CRASH! > > It appears that pressing a key which doesn't result in a direct action > being taken, is not a problem if it is pressed prior to the key that is > defined. If some sort of action is performed immediately before > pressing an assigned key, and the field with the key message handler > remains the one with the focus, then the next assigned key press > triggers a crash for reasons not yet known. > > Can anyone spot an error or omission I've made, or know of a workaround? > > -- > Jacob Wall Is it possible that your message handler is buggy? I think you might be missing a DROP when trapping keycode 7. I usually write my key handler as follows: :: kpNoShift #=casedrop :: kc1 ?CaseKeyDef :: ( process keycode 1 ) ; ... more keycodes .. DROP FALSE ; ... other shift planes ... 2DROP 'DoBadKeyT ( reject all other planes ) ;
|
Pages: 1 Prev: Full Screen with Browser 49 Next: Solved-No Bug (Re: IfMain Bug?) |