Going through the message handlers of the input form from Eduardo's book, I was trying to make a user defined menu different for each field which did not seem to work at all. But when I tried one of those menus in the message handler for the input form as a whole, it did work. So, is it not possible to have different menus for different fields? And what would be a good place to look for the examples of Input form for handling different messages like making fields visible and invisible? Moreover, can the EDIT key in the standard Inputform menu be used to run EDITB command. Because I was tring to make an Inputform in which the allowed field was a matrix. But hitting EDIT would just take me to the text editor whereas if I go in the Stats function built in the calculator, in any of the functions, it would take me to the matrix writer if the allowed object type is a matrix.
> work. So, is it not possible to have different menus for different > fields?
I don't think so. You could do this by making a menu that behaves differently depenidng on which field is selected, but it doesn't appear to be supported.
> And what would be a good place to look for the examples of > Input form for handling different messages like making fields visible > and invisible?
I generally stick them in message 5, which is the one run when any change is made in the field. You can do it anywhere though. You'll use the IfSetFieldVisible command to hide or unhide things.
> would just take me to the text editor whereas if I go in the Stats > function built in the calculator, in any of the functions, it would > take me to the matrix writer if the allowed object type is a matrix.
You'll want to do this using 20 (IfMsgNewCommandLine - only if you want to active a matrix editor when someone types to prevent direct editing ) and 25 (ifMsgEdit). I've pasted the actual message handler from the ROM that is used for this in things like the "single-var" stat form. It is from the old input form which I don't remember if it is any different, so it may be slightly different, but the same general operation will work.
first, this is possible. Second, it is tricky. Third, there is a lot you have to find out by yourself as it is not officially documented.
There are two InputForm engines, DoInputForm and IfMain and they are not compatible, they access memory different and they use different messages.
The description in Eduardo's book covers only the messages for IfMain and the header file for it is included in debug4x, I do not know if all messages of DoInputForm have ever been released, some are covered in 'An Introduction to HP 48 System RPL and Assembly Language Programming' by James Donnelly. I found a Spanish header file once somewhere on the net but I do not remember the website. (Maybe HP could release them officially and send the document to hpcalc.org.)
Fourth, some messages are only for the form, some are only for the fields and some are for both and this depends on the engine ;-)
> But when I tried one of those > menus in the message handler for the input form as a whole, it did > work.
IfMsgGetMenu is only for the form.
> So, is it not possible to have different menus for different > fields?
Yes, and there are different ways possible. You could use the hardkey handler (hard key assignments goes over menu assignments), use LAMs for the menus or IfMsgGetMenu or ... If you want to go with IfMsgGetMenu (I’d recommend in your case) you have to include "dynamic" code in the menu. A menu is
{ "MenuText" <- can be a String, a #MessageBINT or a program which creates your messages depending on conditions
:: TakeOver your menu program, create here dynamically what you need and it will be executed as the menu action. Remember error conditions and low memory conditions ! ;
}
Like I said, it will take some time and work but it can be done, I use a different/advanced/faster technique for the dynamic menus in my TreeBrowser.
If you want to know what is going on while the InputForm is running you can place something like that in your code (in your message handling code, for example) to see which messages are called and when:
DUP (DUP the message number) #>$ DoWarning or FlashMessage or whatever you want to make the message visible
That way you can find out what is going on under the hood (but only at the surface) ;-)
Also search this newsgroup as there have been some descriptions about this in the past.
On Nov 2, 3:26 pm, Gurveer <gurveer....@gmail.com> wrote:
> Hi
> So, is it not possible to have different menus for different > fields?
As others have mentioned, IfMsgGetMenu is only called for the form, but I wonder about IfMsgGet3KeysMenu. Maybe you can use that. Another possibility is to just change the menu using normal RPL commands. If you take this path, change the menu in an IfMsgGetFocus handler and restore it in the IfMsgLooseFocus handler.
> TVM (Time Value of Money) forms (and others) do, > so how do they do that?
Not sure exactly what you mean. The menu keys such as CHOOS and EDIT appear and change reflecting the field type, and in other places items will appear and disappear, but I can't remember one that changes the menu completely when you move onto a new field.
> > but I can't remember one that changes the > > menu completely when you move onto a new field.
> I have some code that does it and as I mentioned it is easiest to do > this in the menu program directly.
Yes, I know. I was referring to a place in the ROM where it does this. I've written some inform boxes that do this as well, although generally I've found that with some thought and rethinking the user experience you don't have to do it.
On Tue, 03 Nov 2009 09:35:39 -0600, TW wrote: >> The "Calculator Modes," "Solve Equation," >> TVM (Time Value of Money) forms (and others) do, >> so how do they do that? > Not sure exactly what you mean. > The menu keys such as CHOOS and EDIT > appear and change reflecting the field type, > and in other places items will appear and disappear, > but I can't remember one that changes the menu completely > when you move onto a new field.
In "Solve Equation," CHOOS appears for the equation, but not for a variable, and SOLVE appears for any variable, while EXPR= appears instead, in the same place, for the equation.
In "Solve Finance" (TVM), SOLVE disappears for P/YR, and both EDIT and CHOOS "flip" (plus some changes on menu page 2) for the Beg/End selection.
Perhaps this is not "changes the menu completely," as in substituting an entire new menu, but items within the menu certainly do change.
Note: You should not hardcode strings as this prevents translation, use a message table instead. GetFocus is 5GETLAM in DoInputForm, this will not work with IfMain, read Informbox.h for IfMain which comes with debug4x.
>I've pasted the actual message handler >from the ROM that is used for this in things like the "single-var" >stat form. It is from the old input form which I don't remember if it >is any different, so it may be slightly different, but the same >general operation will work. >NULLNAME ArrayFP ( ... Msg --> ... T/F ) >:: > IFM_EDITFIELD > #<>case FALSE > EditArray > TRUE >; >** >** Edit a field with the MatrixWriter. >** >NULLNAME EditArray ( --> ) >:: > GetMyFieldId RclFieldVal DoArrayEdit > NOT?SEMI > GetMyFieldId SetFieldVal > ( allow complete display update ) >;
As you said that this is what it is in the ROM, I was just wondering how did you pull that off. I mean like how did you get to know how has that been written in the ROM. And moreover, is it possible to call such functions like the numeric solver and alike in the Stats menu in a program?
> And moreover, is it possible to call > such functions like the numeric solver and alike in the Stats menu in
Not officially, use Nosy to find it out.
However, you won´t be using the built-in numeric solver once you have seen my faster full screen GUILSV which supports the whole screen and all fonts and gives you an extra line if you disable the helpline. And it works on the entire 49 series...
I am currently testing the RC and hope to have a version that I can publish very soon.
> Thanks a lot for the help guys. I need some amount of time to figure > it out completely.
> >I've pasted the actual message handler > >from the ROM that is used for this in things like the "single-var" > >stat form. It is from the old input form which I don't remember if it > >is any different, so it may be slightly different, but the same > >general operation will work. > >NULLNAME ArrayFP ( ... Msg --> ... T/F ) > >:: > > IFM_EDITFIELD > > #<>case FALSE > > EditArray > > TRUE > >; > >** > >** Edit a field with the MatrixWriter. > >** > >NULLNAME EditArray ( --> ) > >:: > > GetMyFieldId RclFieldVal DoArrayEdit > > NOT?SEMI > > GetMyFieldId SetFieldVal > > ( allow complete display update ) > >;
> As you said that this is what it is in the ROM, I was just wondering > how did you pull that off. I mean like how did you get to know how has > that been written in the ROM. And moreover, is it possible to call > such functions like the numeric solver and alike in the Stats menu in > a program?
Seems to be a really good document. Spanish is hard! :)
After a bit of translation, it's making somewhat sense now. Thanks a lot.
> Not officially, use Nosy to find it out.
Thank you for that. Now I know how to use Nosy to find out the programs evaluated by different keystrokes using OT49. But what about those which are not directly accessed like the Input forms which run after the choose box for example in the Stats menu. S?UK asks for a key to be pressed. What if I want to know the InputForm which runs when a NEW variable is to be created in the filer?
maybe you should start with reading the documentation that comes with Nosy.
Nosy can follow the program flow and can put the currently viewed program part on the RPL-Data-Stack. You can use these strings that are put on the stack to build/create parts of the program that you are browsing, that way you might get an overview of what is going on. However ML and interjumps (which will not work in a covered port but the ROM is organized differently so that jumps inside the current flash bank can be made thanks to very fast remapping of the flash banks) are a bit harder to understand and there are some tricks that you can use with the Saturn processor which do not look correct when disassembled.
Also there are parts where Nosy will fail, then use CQIF which will also fail sometimes... And some sources can not even be disassembled, for example a mix of compressed files, ARM enhancements, nasty Saturn tricks and so on...
This is called hacking / reverse engineering and of course not everybody will be happy by that and try to prevent their sources from this. And of course some code does not make any sense without the documented sources.
Conclusion: It takes time, effort and patience to get you where you want but the reward are programms that you can write which nobody else can achieve ;-)
And if you are stuck there might be people here around which know the answer.
> maybe you should start with reading the documentation that comes with > Nosy.
> Nosy can follow the program flow and can put the currently viewed > program part on the RPL-Data-Stack. You can use these strings that are > put on the stack to build/create parts of the program that you are > browsing, that way you might get an overview of what is going on. > However ML and interjumps (which will not work in a covered port but > the ROM is organized differently so that jumps inside the current > flash bank can be made thanks to very fast remapping of the flash > banks) are a bit harder to understand and there are some tricks that > you can use with the Saturn processor which do not look correct when > disassembled.
> Also there are parts where Nosy will fail, then use CQIF which will > also fail sometimes... And some sources can not even be disassembled, > for example a mix of compressed files, ARM enhancements, nasty Saturn > tricks and so on...
> This is called hacking / reverse engineering and of course not > everybody will be happy by that and try to prevent their sources from > this. And of course some code does not make any sense without the > documented sources.
> Conclusion: It takes time, effort and patience to get you where you > want but the reward are programms that you can write which nobody else > can achieve ;-)
> And if you are stuck there might be people here around which know the > answer.
> HTH, > Andreas
Thanks a lot Andreas for providing such a nice insight. I'm an amateur at SysRPL and have no idea about how Assembly Language works. But your post fills me with determination to learn and come up with my answer one day. And I can really feel the joy when I make programs in SysRPL which my classmates could not. I know it takes time but the fruitful results which come out of one's efforts fills one with pride.
Get debug4x and start reading the very comprehensive helpfile, especially RPLMAN.doc and SASM.doc. Use the example projects for your first steps and read the walk through ! www.debug4x.com
I wouldn´t consider myself a professional but reading this suggestions did give me some clues ;-)
On Nov 4, 9:53 pm, Gurveer <gurveer....@gmail.com> wrote:
> Thanks a lot Andreas for providing such a nice insight. I'm an amateur > at SysRPL and have no idea about how Assembly Language works. But your > post fills me with determination to learn and come up with my answer > one day. And I can really feel the joy when I make programs in SysRPL > which my classmates could not. I know it takes time but the fruitful > results which come out of one's efforts fills one with pride.
Gurveer,
Rather than taking up assembly language for a processor that doesn't exist anymore (the Saturn processor is emulated using an ARM processor), consider learning to use HPGCC, the C/C++ compiler for the 50G. It generates native ARM code that is WAY faster than any SysRPL or assembly.
> It generates native ARM code that is WAY faster than any > SysRPL or assembly.
What you forgot: the code is 100 x bigger, needs a specific loader, you have to do everything by yourself as you are outside of Saturn ASM / SYS-RPL and there is no further development of HPGCC, the website is dead for at least half a year.
Helpfull will be ARM ASM as this generates very small code and can be run directly.
As long as the majority of the O.S is still written in Saturn ASM / SYS-RPL and if you want to access this software (like DoInputForm) this can only be done with it.
And if HP keeps compatibility (which they do if they are smart IMvHO) this will be of further use.
People don´t buy hardware, they don´t buy software. What they buy is solutions and part of the solutions is the huge amount of 3rd party software which will be useless otherwise and I doubt that the limited resources HP is given are enough to fill the gap.
Of course this is just my personal nonentity opinion.
|
