Hi,
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?
Cheers!
Meino
Inconsistant way of editing LBL and GTO targets
Inconsistant way of editing LBL and GTO targets
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Re: Inconsistant way of editing LBL and GTO targets
It's normal to have different ways to enter GTO and LBL:
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) :
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.
- 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.
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) :
- keep previous value ([], [a] or [A]), this is the current implementation
- [] HP-42S legacy mode: digit keys will be directly usable for entering numeric labels
- [A] : keyboard will be directly usable to enter upper case labels
- [a] : keyboard will be directly usable to enter lower case labels
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: 00425 - DM41X: β00066 - WP43: 00042
Re: Inconsistant way of editing LBL and GTO targets
Hi,
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?
Cheers
Meino
EDIT: Change some german English to English
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?
Cheers
Meino
EDIT: Change some german English to English
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Re: Inconsistant way of editing LBL and GTO targets
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.
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, DM41X: β00071 & 00656, DM10L: 071/100
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100