fix issue #1612

[pvmm]

This should fix issue #1612

[m9710797]

I must say I'm surprised this works. My expectation was that shortcuts would work strictly hierarchical. And then that the InputText() widget (which uses keys like END) would take priority over the shortcuts in the higher hierarchical level (=the window itself).
I can't test myself right now. But I'll trust your patch. Thanks for trying this!

... Reading the patch in more detail ... I understand that this is only a proof-of-concept patch, but was it the intention to fully skip the call to `ImGui::inputText()' when END is pressed? I think this implies that the text is not drawn on the frame that the END key is pressed.

--

May I ask you to try to extend this PR to not only ignore the END key for text input, but actually make it do some useful stuff? For example:

• Home: move cursor to the start of the line.
• End: move cursor to the end of the line.
• Ctrl+Home: move cursor to the very start.
• Ctrl+End: move cursor to the very end.

I think it's OK if these shortcuts are fixed (not needed to be able to reconfigure them). Also because if it were possible to use something else than END, the problem of issue 1612 would re-appear.

--

Another idea (could be part of this PR, or it could be a separate one):
Maybe we should do something with PgUp and PgDown. I believe currently those control the vertical scroll bar. But maybe it's more logical that they also move the cursor one page up/down.

[pvmm]

Trying to fix InputText externally proved neither easy nor consistent. Sometimes the repeated End key escapes the InputText focus and is captured by the scrollbar, since it's not a proper shortcut. This means that sometimes the End key moves to the very end of the scrollbar and sometimes it doesn't. I think this requires a substitute widget for InputText. So it will take more time to fix it properly.