Inconsistant way of editing LBL and GTO targets

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
Post Reply
Posts: 143
Joined: Fri Jun 23, 2017 3:10 am

Inconsistant way of editing LBL and GTO targets

Post by mcc » Fri May 11, 2018 7:57 am


In a valid program each GTO corresponds to a LBL. Therefore I think, all LBL and GTO should be editable
the same way

To explain for what I want to suggest an improvement is this:

Start a new program:

Enter the global program label.

Now enter GTO. No alpha mode is activated and you can enter number straight away.
Enter a LBL. Alpha mode is activated and you cannot leave it. If the previous alpha mode
was "[A]" or "[a}" you first have to switch to "[ ]" to enter digits. Or you need to shift (YELLOW key)
the according keys.

I would suggest to enable the way GTO is edited for the LBL command too.

I think numerical labels are entered far more often into a program than alpha labels and therefore
should be the most direct reachable ones.

And it would remove an inconsistancy....

What do think?

DM 42 - SN: 00373, Firmware v.:3.5

Posts: 116
Joined: Thu May 04, 2017 10:20 am
Location: France

Re: Inconsistant way of editing LBL and GTO targets

Post by dlachieze » Fri May 11, 2018 8:43 am

It's normal to have different ways to enter GTO and LBL:
  • with LBL you are creating a new label, so you need to be able to enter directly either a alpha of a numeric label, which is exactly what the HP-42S allows by enabling the Alpha mode (there is some difference on the DM42 I will cover below)
  • with GTO you are generally referring to an existing label, so instead of being in Alpha mode the existing Alpha labels are directly accessible with the soft keys, or you can enter a numeric label with the digit keys. In the case of a GTO to an alpha label not yet created you can enable the alpha mode to enter it.
Now the issue you have with LBL is the extended Alpha mode of the DM42 which is redefining the keyboard for direct Alpha entry. As you mentioned when you are not in the 42S compatibility mode ([]) there is a conflict between the direct Alpha entry ([a] or [A]) and the digit keys for numeric label entry. This is a drawback of enabling the keyboard direct Alpha entry on the DM42.

I don't think we should remove the Alpha enabling of LBL as this would break the compatibility with the 42S. What should be addressed is the DM42 specific Alpha mode.

One way to do that could be to have a setting to control the Alpha entry mode for LBL (and only for LBL) :
  1. keep previous value ([], [a] or [A]), this is the current implementation
  2. [] HP-42S legacy mode: digit keys will be directly usable for entering numeric labels
  3. [A] : keyboard will be directly usable to enter upper case labels
  4. [a] : keyboard will be directly usable to enter lower case labels
Option 2 is close to what you propose but it keeps the possibility to enter Alpha numeric labels with the soft keys as on the HP-42S.

So depending on your label usage and preferences you would be able to choose what you want. May not be ideal but offers more granularity than the current implementation.
DM42 SN: 00425

Posts: 143
Joined: Fri Jun 23, 2017 3:10 am

Re: Inconsistant way of editing LBL and GTO targets

Post by mcc » Fri May 11, 2018 2:34 pm


another idea:

In both cases (that is LBL and GTO): Let the user decide.
Pop up the alpha menu and stay in numerical input mode.
When a menu key (top row) is pressed, change in alpha mode and
"return" the according label name.
If a new alpha string needs to be entered, do what you usually do:
Enter alpha mode manually.
If a numerical label "name" needs to be entered: Just do it.

What do you think?


EDIT: Change some german English to English ;)
DM 42 - SN: 00373, Firmware v.:3.5

Posts: 333
Joined: Mon Apr 24, 2017 5:48 pm
Location: New York

Re: Inconsistant way of editing LBL and GTO targets

Post by rprosperi » Fri May 11, 2018 4:50 pm

When the extended Alpha mode was first released (during beta testing) there were many (many!) variations suggested, debated, and even tested. The result was what we have today, so this is not new territory.

This is not to say it is perfect or that it could not be improved (as Didier's suggestion shows) however the core reason this remained as-is, despite this exact issue being somewhat annoying, was to keep extended Alpha use simple, consistent (e.g. no special alpha sub-modes or 'tricks' to activate only when such-and-such happens) and predictable. Though I was not happy with this exact issue (I still press the numbers first and get letters), in the end after much discussion, this compromise seemed to make the most sense, and the best use of David's time.

As this still bugs me, I hope this could be revisited someday, but there are many far higher priorities that need work before coming back to this, since it really is only a minor annoyance with easy workaround. Just one opinion.
--bob p

DM42: β00071 & 00282

Post Reply