On my 48GX I would write a program to keep my main programs at the
front (left most side) of the VAR menu. The program would look like
this:
<< {A B C D} ORDER >> I would execute the program and it would move
variables for A B C and D to the left.
On the 49G+, when I run the program with variables in the directory
besides the ones listed, I get an error:
ORDER Error:
Invalid Syntax
When I run the program and the variables in the list are to the left, I
don't get an error.
Is there something I can do to keep from getting the error on the 49G+?
I don't understand why I am getting an error.
****************
Next question. I want to exectue the NXT function from a program. In
other words, I want to execute the NXT funtion to rotate the soft menu
to the next page. I also want to have a softkey that acts like the VAR
key. I have not found a way to perform these methods and was hoping
someone could be so kind to clue me in. I am going bonkers on this
one.
TIA!! :-)
You shouldn't get an error here. Are you sure you're in RPL mode? a
"Syntax Error" only happens when you validate a command line and the
syntax in the command is ... incorrect
> ****************
>
> Next question. I want to exectue the NXT function from a program. In
> other words, I want to execute the NXT funtion to rotate the soft menu
> to the next page. I also want to have a softkey that acts like the VAR
> key. I have not found a way to perform these methods and was hoping
> someone could be so kind to clue me in. I am going bonkers on this
> one.
RCLMENU .01 + STOMENU
but the screen will only be updated when it completes. This is
equivalent to do NEXT
Maybe also using KEYEVAL
VPN
> "Jean-Yves Avenard" <m...@privacy.net> wrote in message
> news:3n7lcp...@individual.net...
> > aplnub wrote:
> > >
> > > When I run the program and the variables in the list are to the left, I
> > > don't get an error.
> > >
> > > Is there something I can do to keep from getting the error on the 49G+?
> > > I don't understand why I am getting an error.
> > >
> >
> > You shouldn't get an error here. Are you sure you're in RPL mode? a
> > "Syntax Error" only happens when you validate a command line and the
> > syntax in the command is ... incorrect
> >
> >
> > > ****************
> > >
> > > Next question. I want to exectue the NXT function from a program. In
> > > other words, I want to execute the NXT funtion to rotate the soft menu
> > > to the next page. I also want to have a softkey that acts like the VAR
> > > key. I have not found a way to perform these methods and was hoping
> > > someone could be so kind to clue me in. I am going bonkers on this
> > > one.
> > RCLMENU .01 + STOMENU
I don't have a STOMENU command on my 49+, but MENU works, as in
RCLMENU .01 + MENU
VPN's suggestion of
33 KEYEVAL
works too.
Either will cause the menu to go to the next page, but one does not see
the changed MENU during program execution unless one follows it with
-1 WAIT
But that stops the program, waits for a keypress, and puts the keycode
on the stack before proceding.
To get the next page of the menu visible then stop to require a keypress
for the new menu try something like
33 KEYEVAL WHILE -1 WAIT DUP 17 > REPEAT END KEYEVAL
The WHILE loop rejects all but softkey keypresses and the CANCEL (OFF)
key, and the last KEYEVAL executes the softkey from its keycode.
Unless you tell us more about why you want to page the softkeys, this is
about the best we can do.
ORDER
Yes, I am in RPN mode. I can't use Algebraic since I have been on the
48 series for 10+ years. :-)
There is DEFINITELY an error with this program.
Here is my program and the name is OME:
<< { TANK1 CAL1 CAL2 CAL3 V1 OME } ORDER >>
If I run this program and the variables are in anyway out of order and
not the leftmost variables in the VAR menu for that directory, I get an
syntax error, if I run that program and the variables are all in the
correct order to the leftmost side of the var menu in that directory, I
don't get an error.
For instance, lets say you enter those variables into your directory,
if I create a new variable after all those named WWXXTT, and then run
OME, I get the syntax error. However, on my 48G it works perfect. I
have rewritten the program on the 49G+ from the editor just in case I
had a problem going from 48GX to 49G+.
*********************************************
Executing normal keys in programs.
Again, thanks for the responses.
I want to have a soft key that is the NXT key instead of having to use
the NXT key. That is my ultimate goal. This way, new users of my
program will know there is another page of soft keys to be used if
neccessary.
> Thanks for all the help so far! :-)
>
> ORDER
>
> Yes, I am in RPN mode. I can't use Algebraic since I have been on the
> 48 series for 10+ years. :-)
>
> There is DEFINITELY an error with this program.
>
> Here is my program and the name is OME:
>
> << { TANK1 CAL1 CAL2 CAL3 V1 OME } ORDER >>
>
> If I run this program and the variables are in anyway out of order and
> not the leftmost variables in the VAR menu for that directory, I get an
> syntax error, if I run that program and the variables are all in the
> correct order to the leftmost side of the var menu in that directory, I
> don't get an error.
>
> For instance, lets say you enter those variables into your directory,
> if I create a new variable after all those named WWXXTT, and then run
> OME, I get the syntax error. However, on my 48G it works perfect. I
> have rewritten the program on the 49G+ from the editor just in case I
> had a problem going from 48GX to 49G+.
I get an error message and interupt, too.
AS a kludge, try replacing the ORDER command with
IFERR ORDER THEN END
On my 49+ the desired reordering is then actually done but without any
unwanted side effects. At least none that I have as yet discovered.
>
>
> *********************************************
>
> Executing normal keys in programs.
>
> Again, thanks for the responses.
>
> I want to have a soft key that is the NXT key instead of having to use
> the NXT key. That is my ultimate goal. This way, new users of my
> program will know there is another page of soft keys to be used if
> neccessary.
Do I understand that you want the program to pause for a softkey
keypress but be able to browse through more than one page of softkey
options before making one's choice?
To set up your menu with less than 7 menu items you might use something
like this:
{ A B C D E F} TMENU -1 WAIT IF DUP < 17 THEN KEYEVAL ELSE DROP
THis will halt the program to wait for a keypress. If the keypress is a
softkey, it will be executed before the program continues, but any other
key (except CANCEL) will cause the program to continue without executing
a soft key. The CANCEL key (the ON key) will abort the program as usual.
To allow simple paging, insert
{ "NXT" \<< 33 KEYEVAL -1 WAIT \>>}
after each 5 regular menu items ( so as to be the last item on each
page) except at the end.
To allow going back to previous pages too, insert instead
{ "NXT" \<< 33 KEYEVAL -1 WAIT \>> \<< 33.2 KEYEVAL -1 WAIT \>> }
after each 5, and at the very end as well.
Is this along the lines of what you had in mind?
I needed that already with the old 49G, too
The OS is twice the size of the 48GX and filled with bugs
VPN
> On my 48GX I would write a program to keep my main programs at the
> front (left most side) of the VAR menu. The program would look like
> this:
>
> << {A B C D} ORDER >> I would execute the program and it would move
> variables for A B C and D to the left.
>
> On the 49G+, when I run the program with variables in the directory
> besides the ones listed, I get an error:
>
> ORDER Error:
> Invalid Syntax
>
> When I run the program and the variables in the list are to the left,
I
> don't get an error.
This is obviously a bug on HP 49G and hp 49g+ up to ROM 2.0
Here is my little test program, I have used for checking
%%HP: T(3)A(R)F(.);
DIR
A
\<< { D C B A } ORDER
\>>
B 1.
C 1.
D
\<< { A B C D } ORDER
\>>
END
Storing this directory and excecuting A
will *start ordering, but excecution is
interupted, with the error message you have written above.
On HP 48GX ist works, like it should do.
regards
Heiko
The problem seems to be that, although the ORDER command is still
executed, in the process an error interupt is sometimes generated.
An easy, but kludgey, fix is to replace each
ORDER
by
IFERR ORDER THEN END
In this case the order command is properly executed but the program
interupt is bypassed.
If there is anything which is not a name in the current directory, or a
list containing such non-names, as argument, then
IFERR ORDER THEN END seems to simply ignore them and reorder based on
actual names.
But it is a bug that should be fixed!
What seems to be happening to me is that when you execute A (assuming vars
are ordered A B C D), the error comes from trying to move the object that is
being run. If A is at the rightmost place, running it causes no error, if it
is not the rightmost object (among the moved objects), it errors. If you RCL
the content of A and try to execute it, same error, however, if you open it
and save it unchanged or run NEWOB, you don't get any error. So, as I see
it, ORDER tries to alter the obects stored, including the one calling ORDER
to place them starting with the rightmost in the list. So if the one calling
is already the rightmost, all the other go to its left and it is unchanged.
If it's not already the rightmost, ORDER tries to move the object being run,
which causes an error and is returned as syntax error.
A "clean" fix is to have the ORDER using program in a seperate variable
(lest's say ORD) and call it using 'ORD' RCL NEWOB EVAL
> Storing this directory and excecuting A
> will *start ordering, but excecution is
> interupted, with the error message you have written above.
>
> On HP 48GX ist works, like it should do.
>
> regards
> Heiko
>
>
Regards,
RL
The ORDER command is the one written by Mika Heiskanen and was
introduced in the 49G when ALG48 was integrated in the 49G.
The chance for it to be corrected are virtually nil.
Jean-Yves
Correct, Jean-Yves!
I just talked to Mika Heiskanen on the phone
and he told me that he released most of his code
including ORDER command for "free to use" to HPQ
during the v'ger project and
that he has nothing left of the environment or code
since his Windows PC hard disk failed
He has only Linux on his new PC.
Also
he noted that it would be _easy_ for HP
to remove the subroutine call to the error echoing
Good luck, Cyrille!
VPN
I will still hope that it gets fixed though. :-)
> Bummer. I use that command a lot. :-(
> I will still hope that it gets fixed though. :-)
You can fix it yourself, just as someone already suggested:
On HP49G[+] *ONLY*:
\<< RCLF SWAP -55. SF #3E8F0h IFERR SYSEVAL THEN END STOF \>>
HOME "ORDER" #100016h LIBEVAL STO
Now you have a variable named 'ORDER' in your HOME directory,
containing a program which invokes the built-in ORDER
with an error trap, ignoring any errors.
Every time you edit (or re-edit) a UserRPL program on your calculator,
the word ORDER will be re-compiled into that program name
in place of directly executing the built-in internal command.
Caution: I recommend that you BACK UP YOUR MEMORY before using
any programs containing SYSEVAL and/or LIBEVAL.
[r->][OFF]
If you want to use the ORDER menu key in built-in menu 71,
however, you should first enter the "Program editing mode"
(right-shift ENTRY will do that for you).
[r->][OFF]
No, that would not work.
First of all IFERR depends on flag -55 and
second, after error checking ORDER need to be applied again,
until no error occures.
I think it would be better to take the HP 49G-series routine, which
works perfekt. Thanks to the "Corvalis Team", or however the writing is
:-).
Best regards
Heiko
I made a lot of testing and found it works sometimes, and sometimes not.
I don`t take care!
It is a ugly bug on HP 49G and followings!
I remember, struggling before with this problem and it is more than a
pitty,
that a simple ordering routine is not working like it did before on HP
49G-Series.
In my opinion there is a great chance to get it debuged for the next
ROM, because
I will complain additionaly directly to my wholesaler,
and you all, should do as well!
Regards
Heiko
A much cleaner and safer way (imho) is to do very minor editing to your
program:
if it was << some commands here {var list} ORDER more commands here >>, all
you need to do is to rewrite it into:
<< some commands here {var list} NEWOB ORDER more commands here >>
It also makes ORDER behave like it's supposed to.
If you want to be convenient or something, make a var called ORDR that
contains that,
\<< NEWOB ORDER \>>
>
> [r->][OFF]
NEWOB, now there is something I had forgotten. Btw, I name my ordering
programs, ORDR, weird!!!!
Did you actually try it?
I tried it in several programs and it worked in all of them, reordering
whereever the reordering program was listed in the soft menus or in the
list specifying the new order, and could not get it to fail.
Can you give me an example of a program where it fails?
> On HP49G[+] *ONLY*:
>
> \<< RCLF SWAP -55. SF #3E8F0h IFERR SYSEVAL THEN END STOF \>>
> HOME "ORDER" #100016h LIBEVAL STO
...
> Caution: I recommend that you BACK UP YOUR MEMORY before using
> any programs containing SYSEVAL and/or LIBEVAL.
Sorry, I did not try your procedure,
but it looks like it does not make the job because the build in
ORDER-command may need to be called several times, before the job
is done. See my example in this thread.
Excuse me, if I am wrong.
By the way, the problem may not occur when you make the order-procedure
by typing a list, followed by ORDER?
Best regards
Heiko
> Did you actually try it?
Yes, search within this thread, and I allready gave an example.
"Heiko Arnemann" <Heiko.A...@gmx.de> schrieb im Newsbeitrag
news:4311b2aa$0$21686$ba62...@news.skynet.be...
Yes, and sometimes it starts the ordering procedure but does not
complete.
Try my example :-)
Regards
Heiko
> Soemtimes, it would leave the list of variables to be ordered on the
> stack after it ordered the variables. That is not a failure by any
> means.
Although you might not consider it serious for *manual* operations,
it would be a failure for any command used in a program to leave
any *unpredictable* (or unknowable) number of results on the stack,
because then the program would lose the ability
to keep track of what was on the stack, which is often
rather essential for proper function of programs.
By the way, certain built-in commands (DOLIST, DOSUBS, SEQ)
already suffer from this oversight, because if any program
is written to leave a variable number of results on the stack
during the execution of those commands, the fact that
if the "variable number of results" goes down to zero,
then *no* list (rather than an *empty* list) gets returned
has always needed some special or defensive programming
to compensate for that unthoughtful behavior.
As first noted in 1996:
http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/a266a0ae34acc079/b61229d8d67cba7f
If it turns out that NEWOB is all you need to fix ORDER,
then you can still create your own ORDER program in HOME
to intercept every other ORDER in subsequently edited or
ascii-transferred UserRPL programs (or typed command-line entries):
On HP49G[+] *ONLY* (don't forget to BACKUP MEMORY before use!)
\<< NEWOB #3E8F0h SYSEVAL \>> HOME "ORDER" #100016h LIBEVAL STO
As you can guess, #3E8F0h is the (supported, fixed-location)
address of ORDER in the HP49G ROM, and #100016h LIBEVAL
is the S~N command, built into "development" library 256.
[r->][OFF]
This is probably the case, as I have not noticed it when typing the list.
BTW, that's the only way I use it.
Scott
>
If I remember correctly, Mieka's ORDER routine was used because it was
infinitely faster than the 48G ORDER program.
There were many cases where the original ORDER program was incredibly slow.
JY
Using NEWOB as cured the problem and ORDER is super fast on the 49G+.
Ohh, yes, you are right.
> If I remember correctly, Mieka's ORDER routine was used because it was
> infinitely faster than the 48G ORDER program.
>
> There were many cases where the original ORDER program was incredibly
slow.
Ja, this explains the decission, but the decission was not ok, when
ORDER is
not working properly anymore.
Best regards
Heiko
> the original [HP48S/HP48G] ORDER program was incredibly slow.
And so was VARS, which is probably why the HP48 "Hacker's ROM"
(plug-in card) included replacement faster VARS and ORD commands
(the latter by Mika Heiskanen, as included in HP48 Goodies Disk #10).
[r->][OFF]