From: Jacob Wall on
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
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
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 )

;