program editor line-insertion issue

[c785]

Hi there,

I really appreciate the big screen allow multi-line program display, it makes writing programs so much more comfortable. Now there's an issue here, however: When I go to a line and start entering a new line (which will be inserted after the line I moved the cursor to), the cursor (correctly) jumps to the next line, but wrongly overwrites the next line instead of shifting the rest of the program down by one line. This doesn't matter for single-key lines, but it matters a lot for anything requiring more than one keypress (LBL, GTO, STO, RCL, alpha, etc., the list is endless). Effectively, it blanks out the next line of the program during entry, which is very confusing. After the line is complete, everything is moved to its right place and displayed correctly, it's just during editing that a line of code temporarily disappears.

I know this might even be a Free42 issue specific to the DM42 because this behaviour simply doesn't matter on a two-line display, but I find it quite annoying and would appreciate it being fixed.

[toml_12953]

+1

[Thomas Okken]

I know this might even be a Free42 issue specific to the DM42 because this behaviour simply doesn't matter on a two-line display

Ahem. A "Free42 issue specific to the DM42" is a DM42 issue. Excuse me for not implementing support for displays with more than two lines, in my app that has a display with exactly two lines. The same two lines that the HP-42S display has. The HP-42S that started this whole thing.

"Lack of functionality I would like to have" is not the same as "bug" or "issue."

Thank you, carry on. I'm going to have a beer now.

[Geoff Quickfall]

gaaaaaaazzzzzzzzzzziiiiiiiiiiinnnnnnnnnnggggggggg

Well done Thomas

[rprosperi]

Note that sometimes it appears to push the lines below it down properly, while at other times it overwrites the next line and the 'hidden' line is not restored until the current line entry is completed, as described above.

For this fragment:

Code: Select all

01 LBL "AAA"
02 STO 00
03 X
04 COS

If your cursor is on line 03 and you press [1] (starting numeric entry) the 'COS' line is hidden until you complete the line you just started with the 1.

But if you press [*] the new * command is inserted and lines below are properly pushed down.

They are both actually doing the same thing, it just happens immediately in case 2 since the [*] key both begins and ends that command, so upon ending, the display of lower lines is restored.

No magical insight here, just posting this short explanation to avoid a bunch of "I can't reproduce this, it's not a problem" posts.

And finally I agree with both comments. It's not a bug (and certainly not in Free42), but I too would like it changed to behave as we expect.

[Thomas Okken]

Note that sometimes it appears to push the lines below it down properly, while at other times it overwrites the next line and the 'hidden' line is not restored until the current line entry is completed, as described above.

For this fragment:

Code: Select all

01 LBL "AAA"
02 STO 00
03 X
04 COS

If your cursor is on line 03 and you press [1] (starting numeric entry) the 'COS' line is hidden until you complete the line you just started with the 1.

But if you press [*] the new * command is inserted and lines below are properly pushed down.

They are both actually doing the same thing, it just happens immediately in case 2 since the [*] key both begins and ends that command, so upon ending, the display of lower lines is restored.

No magical insight here, just posting this short explanation to avoid a bunch of "I can't reproduce this, it's not a problem" posts.

And finally I agree with both comments. It's not a bug (and certainly not in Free42), but I too would like it changed to behave as we expect.

I agree, but I would also like to point out that this has been discussed here already, and quite recently: /viewtopic.php?f=17&t=476&p=5569#p5569.

[Walter]

... I would also like to point out that this has been discussed here already, and quite recently: /viewtopic.php?f=17&t=476&p=5569#p5569.

I concur.

[c785]

I know this might even be a Free42 issue specific to the DM42 because this behaviour simply doesn't matter on a two-line display

Ahem. A "Free42 issue specific to the DM42" is a DM42 issue. Excuse me for not implementing support for displays with more than two lines, in my app that has a display with exactly two lines. The same two lines that the HP-42S display has. The HP-42S that started this whole thing.

"Lack of functionality I would like to have" is not the same as "bug" or "issue."

Thank you, carry on. I'm going to have a beer now.

Sorry if you feel offended, Thomas, but I was merely pointing out that the best way of tackling the issue might be by modifying Free42 code, not the non-free DM42-specific OS. But then again, I might be completely wrong because I have no knowledge of the internals of Free42 or DM42.

And I hadn't found the other thread during my search, sorry for that as well.

The issue still stands, and I'm happy that others have reported it too, so it might actually get fixed at some point.

[Thomas Okken]

I was merely pointing out that the best way of tackling the issue might be by modifying Free42 code, not the non-free DM42-specific OS.

As I understand it — and I could be wrong, I haven't seen their code, either — proper large-screen support for code editing will have to be implemented in the "Free42" part of the code.

They maintain a patch that represents the difference between the upstream version of the code and theirs, which they apply to the Free42 source code releases to obtain their version.

Which functionality is in that patch and which is in the DM42 OS will be revealed when the DM42 code and development tools are released...

[c785]

Thanks, Thomas, for the insight. In your last sentence, you say "when", but as it stands, I think an "if" in its place would be more realistic. I still hope, however, that they do release the code one day.