ws3270 cursor set at wrong position

[feujun]

Describe the bug

When entering text into an input field and reaching its end, the cursor moves just one position down from the last character.

To Reproduce

Use any available input field without another input field in the same line like here:

The screenshot shows the CICS-transaction CETR because it is supplied with CICS and shows no further information. I can however reproduce the error in all screens, CICS and not-CICS.

Fill the whole field with characters and after the last char the cursor jumps to the field directly below.

Expected Behaviour

The cursor jumps to the start of the next available input field, i've marked it red in the screenshot above. This was also the behaviour in Version v4.0ga12 and is still the behaviour in wc3270.

Edit: I don't know in which version the bug was introduced and didn't test other versions. v4.0ga12 is just the last version that i know does not contain the bug.

Environment

• Operating System: Windows 10 Enterprise 20H2 (if that's relevant)
• ws3270: s3270 v4.1ga12 Mon Feb 21 17:35:40 UTC 2022 pdm

[pmattes]

Interesting -- this is an area of the code that has not changed in quite some time.

To help me figure this out, I need you to capture a data stream trace of the screen when this issue occurs. You can just turn on tracing and then turn it off. The trace file will include a snapshot of the screen contents.

It would also help if you have access to a different 3270 emulator (hopefully not one based on x3270) to see if the behavior is as you expect.

[feujun]

I thought that too, because none of the changelogs in the wiki show any changes to that area.

Here is the trace-file: cursor.txt I had to change the filename for the GitHub-Upload and had to change some entries, which show data specific to myself (install location and the hostName in the prompt line), but the rest is unchanged, so i hope there's some useful information in it :)

I did check the behavior with ye olde IBM Host on Demand™ and it did jump to the start of the next input field (which is expected behavior).

[pmattes]

Great find!

It does work properly when used interactively. It also works properly if you use 'Key(f)' instead of 'String(f)' to add that final character to the field.

The bug was in the logic called by the String() action. It was applying margined paste semantics when it should not have.

I have committed a fix to 4.1 and master. If you are building your own from source, you can get that now on github. It might be a little while before I can package up a new Windows release. If you need new binaries sooner, please let me know and I will cut a pre-release for you.

[feujun]

New binaries won't be necessary right now, as long as the fix is included in the next release 😉. I'll just close this issue then. Thanks for the fix!