Prev: IfMain Bug?
Next: Can I define a constant as a library entry
From: Jacob Wall on 1 Aug 2010 12:21
Thanks for replying Han. I think that you may be thinking more of a POL
hard key assignment situation? Similar concepts, however the IfMain
message 0 behaves slightly different from what I can tell, but you bring
forward some ideas that I didn't think of. Let's examine the message
handler:

>> '
>> ::
>> BINT0
>> #=case
>> ::
>> OVER
>> BINT7
>> #=case
>> ::
>> 2DROP
>> "Key Assigned!"
>> FlashMsg
>> TRUE
>> ;
>> FALSE
>> ;
>> FALSE
>> ;

BINT0 ( IfMsgKeyPress � 0 )
#=case
::
...
TRUE
;
FALSE

I broke the sample code down to its simplest form, therefore no DEFINEs
or INCLUDEs. The key message handler is the only one I'm interested in,
and I don't see an issue with the general form of the message handler
structure. I could use:

#0=case
::
...
TRUE
;
FALSE

or

DUP#0=csedrp
::
...
TRUE
;
DROPFALSE

or ?, but none of that makes any difference in the end result. From
programming in System RPL:

----------------------------------------
35.8.2.1 IfMsgKeyPress � 0

This message is sent after each keypress, first to the active field,
then to the input form. If the field handles the message, the normal
input form key handling is not executed.

Input 2: #KeyPlane
1: #KeyCode

Output (if handled) 2: ::Key_Handler_Program
1: TRUE

Output (if not handled) 3: #KeyPlane
2: #KeyCode
1: FALSE
----------------------------------------

First of all, I believe the 'Input' stack diagram is shown incorrect, it
should be:
Input 2: #KeyCode
1: #KeyPlane

By association, the 'Output (if not handled)' stack diagram is then also
not correct. Anyways, the output is handled for message 0. Looking at
the 'Output (if handled)' stack diagram I thought maybe I should try the
following to intercept the desired key:

OVER
BINT7
#=case
::
'
::
2DROP
"Key Assigned!"
FlashMsg
;
TRUE
;
FALSE

Interestingly enough, no crash, but an error instead. At this point I
realize that I should be doing the key handling properly for each
#keyplane, and make use of ?CaseKeyDef as suggested by Han. Also
looking at the documentation for the POL hard key assignments, I came up
with the following for the field message handler:

'
::
#0=case
::
BINT1
OVER#=case
::
OVER
BINT7
?CaseKeyDef
::
TakeOver
2DROP
"Key Assigned!"
FlashMsg
;
DROPFALSE
;
FALSE
;
FALSE
;

THIS WORKS! It appears that I had a fundamental misconception of how
this message works. Funny how a suggestion by someone (Han) followed by
trying to talk myself through it, ends in finding the error.

No Bug, and I'll post this message unedited, the result of a lengthy
endeavor.

Thanks Han,

Jacob

From: Han on 1 Aug 2010 18:05
Congrats and getting your program to work. I remember also running
into many problems with the key handlers back on the HP48 calculators.
It was often due to the misnaming and/or misdocumentation of control
symbols in the "case" family.

For example, #=casedrop has the following stack diagram:

#x #y -> (if #x = #y)
#x #y -> #x (if #x <> #y)

:: ... #casedrop objectTRUE ... ;

So #=casedrop actually does the equivalent of

.... OVER #= case :: DROP Obj_TRUE ; ... rest of runstream

whereas the name suggests it should do

.... #= case :: DROP Obj_TRUE ; ... rest of runstream

(At least that was the behavior for the HP48 series.)

 | 
Pages: 1
Prev: IfMain Bug?
Next: Can I define a constant as a library entry