Any 42S means to keep a Global Label hidden from XEQ and other menus?

[burkhard]

I think I probably know the answer to this, but as I fiddle with my 42S and Free42, I'm wondering if there is some way to keep certain global labels from appearing on menus like XEQ, CATALOG→PGM, and GTO?

Here's why: Say I load up a program like the nice unit converter "Convert" by Ton van de Burgt that is listed on Thomas Okken's site http://thomasokken.com/free42/42progs/index.html

It has a main front-end program called "CONV" whose only real purpose is to set up the soft menu with the 11 KEYX commands that access each of the other 11 programs (LENG, AREA, VOL, TIME, SPEED, MASS, and on the next row FORCE, ENRG, POWR, PRESS, TEMP) that do the actual conversions. Since these 11 unit programs are separate programs from CONV, they each need to be called from CONV via their own global rather than local label (e.g. XEQ "LENG" instead of XEQ 01). But once they are defined via global labels, they show up (and clutter up) CATALOG→PGM, XEQ, and GTO menus.

Ideally, I'd like to only access them through CONV and never see them present in the XEQ menu for example. They take up two rows on their own, which means that other programs of mine are a little harder to find, especially when I've got bunch like that.

Is there some way to suppress global labels we don't want on the menus? I suspect there is not and the "solution" is to rewrite CONV to be a big single program with the 11 menu choices handled as local labels within it.

Alternatively, I could just put the programs I actually want to see on the Custom menu and cease using XEQ. I tend to use the Custom Menu more for functions like R↑ at present.

Any other ideas? I find having every global label on the menus very cluttering. Thanks much!

[Thomas Okken]

(10-04-2018 06:17 PM)burkhard Wrote:  Is there some way to suppress global labels we don't want on the menus? I suspect there is not and the "solution" is to rewrite CONV to be a big single program with the 11 menu choices handled as local labels within it.

There is no way to hide global labels from the menu, so your suspicion is correct, the only solution is rewriting CONV (and similar multi-part programs) to be one big program, using local labels for everything except the initial entry point. Note that this will typically require not just changing global labels to local ones, but also changing local labels where they clash after merging programs.

[Valentin Albillo]

(10-04-2018 07:05 PM)Thomas Okken Wrote:  Note that this will typically require not just changing global labels to local ones, but also changing local labels where they clash after merging programs.

It's probably not the case here but with other programs changing local labels to fix clashes could require further nontrivial changes if some of the programs do use indirect addressing to numeric local labels (i.e.: GTO/XEQ IND 01 or IND ST X, say) lest said programs would stop to work properly.

Regards.
V.
.

[burkhard]

Thanks, guys for the thoughts on this. It’s not the end of the world of course, but I just like things tidy. I might do some of that “combining” for my favorite programs and will keep it in mind for the future as well.

[Didier Lachieze]

A way to keep things tidy on the DM42 is to have different saved calculator states to keep things separated (as if you had different calculators, each loaded with a different set of programs). For example you can have one with CONV and another one with your other programs.

[Paul Dale]

The global visibility of all alpha labels is one thing I dislike most about the 41/42 calculators...

You're not alone.


Pauli

[Massimo Gnerucci]

(10-05-2018 06:34 AM)Paul Dale Wrote:  The global visibility of all alpha labels is one thing I dislike most about the 41/42 calculators...

You're not alone.


Pauli

Only global alpha labels. And on purpose, since they are usually meant to be XEQted. Otherwise use local labels, alpha or numeric: besides they are located faster.

[Paul Dale]

It is more about programs I type into the calculator. Lots of people use alpha labels for things that ought not be exposed globally.

Pauli

[burkhard]

It would seem that a middle ground option between global and local would be nice, labels which could be accessed from anywhere by the machine, but wouldn't pop up on every menu, cluttering it. Maybe you could still spell it out if you really wanted to GTO it or even XEQ it...

Perhaps for the 43S, Pauli? :-)

[Thomas Okken]

Hmmm, that could be achieved by hiding all labels that start with a certain character. I'd personally like it if I could do that Unix-style, hiding everything that starts with a period, but that would cause problems because I've seen such labels actually being used as user-callable labels. But if the magic character were one that is impossible to type on the real 42S, it wouldn't cause any backward compatibility issues, except possibly with HP-41 code that uses weird synthetic global labels (or are there characters that you can type on the 41 but not on the 42S?).

Of course "impossible to type on the HP-42S" means "impossible to type in Free42" as well, so maybe I'll have to add a character to the ALPHA menu somewhere to make this work.

Hmmmm....

EDIT: Or just do the Unix thing anyway, and add an option to Preferences to turn the hiding behavior on and off. People who use legacy code that contains user-callable labels that start with a dot *and* want to use the hiding feature would have to modify their code, and everybody else would be fine without any hassle.

Thoughts?

[Thomas Okken]

The semicolon might be a good choice for the magic character. I don't think I've ever seen it used as the first character of a global label, it's impossible to type on the 41 so it won't show up in non-synthetic legacy 41 code, and it is used as the comment delimiter in certain languages, so there is a nice "ignore this stuff" kind of association with it as well.

[Massimo Gnerucci]

From http://www.greendyk.nl/hp41c-manual/inde...&m=J&p=110

Quote:Program labels that are ALPHA characters can consist of any seven ALPHA characters except , (comma), . (period), : (colon).

So a period should do the trick.

[Thomas Okken]

(10-05-2018 02:13 PM)Massimo Gnerucci Wrote:  

Quote:Program labels that are ALPHA characters can consist of any seven ALPHA characters except , (comma), . (period), : (colon).

So a period should do the trick.

As far as HP-41 compatibility is concerned, yes, but those three characters are not forbidden in label names on the HP-42S.

Whether or not they make good magic characters for hiding labels in Free42 depends on whether they are actually used as initial characters in label names in existing HP-42S programs. I know I've seen periods used as first characters, so those could only be used as the magic character if label hiding is an option that can be turned off. Comma or colon might be OK. I'm going to have to take a look at my code collection to see which characters might qualify...

[StephenG1CMZ]

With computer compilers, I have often seen the underscore used to identify "internal" symbols - but I don't know if that would suit the 42. An alternative to a specific character might be any name longer than the allowed 7, perhaps?

[Massimo Gnerucci]

(10-05-2018 02:26 PM)Thomas Okken Wrote:  As far as HP-41 compatibility is concerned, yes, but those three characters are not forbidden in label names on the HP-42S.

Oh yes: my note was about possible issues with legacy (41) programs.

Trying to remember if there was a way via Synthetic Programming to put a period in a label...

[Dave Britten]

How about this: prefix with a colon to hide from the XEQ menu, prefix with a period to hide from XEQ, solve, and integrate. Don't hide anything from GTO, since that's used interactively for development purposes most of the time.

[burkhard]

Wow, you guys are great. It's rewarding to ask a newbie question and open up some good discussion.

[Paul Dale]

What about changing the user input for LBL, GTO and XEQ (& other?) so a different key press marks a local alpha label? Kind of like shift and . doing special things already.

"GTO TAN" puts you into alpha input mode with a local prefix already present? TAN being the L key. The implementation could prefix a non-typable character as part of the alpha input or it could add a local flag.

Pauli

[Dave Britten]

(10-05-2018 10:47 PM)Paul Dale Wrote:  What about changing the user input for LBL, GTO and XEQ (& other?) so a different key press marks a local alpha label? Kind of like shift and . doing special things already.

"GTO TAN" puts you into alpha input mode with a local prefix already present? TAN being the L key. The implementation could prefix a non-typable character as part of the alpha input or it could add a local flag.

Pauli

To build on that idea a bit, what about another instruction placed just before the LBL step that changes its behavior? Perhaps if an "X=0?" is seen just before a LBL, leave it out of the XEQ list, and "X=Y?" leaves it out of XEQ, solve, and integrate? I can't think of any legitimate programming tricks that would interfere with, but maybe you guys can.

[Mark Hardman]

Rather than a specially formatted global label, why not formally implement local labels using somethnig like LLBL?