Return the old Content.setKeyPressCallback functionality (that we had for a few days)

[Casmat]

@d-healey Yup, on windows, not able to type in the label, on Aug 13 commit

[d.healey]

@ulrik said in Return the old Content.setKeyPressCallback functionality (that we had for a few days):

Typing works but return, esc and backspace doesn't do anything.

Typing is the thing I'm testing. But yes the other issue is also important, although I think you have to add some more code for those things, no?

@ulrik said in Return the old Content.setKeyPressCallback functionality (that we had for a few days):

Which commit are you on?

7th of August.

[aaronventure]

@d-healey said in Return the old Content.setKeyPressCallback functionality (that we had for a few days):

Typing is the thing I'm testing. But yes the other issue is also important, although I think you have to add some more code for those things, no?

No, it breaks the base label functionality of pressing enter to exit the edit mode and have the entered string move to the set alignment position. You also cannot exit the edit mode with ESC; the only way is to click somewhere other than the label itself.

But yeah, on Windows, it prevents any entry if the callback exists.

[d.healey]

@aaronventure Thanks for confirming!

[aaronventure]

@aaronventure It seems that the Windows version actually consumes the key pressed, as on the macOS, the callback obj doesn't fire when you type.

On Windows it does. I'm somewhat lost as to what the behaviour should be on the label with this. I imagine it should be as it is, because there's an option to "disable" the label, which we should do if we want key presses to interact with it visually?

So it's bugged on all platforms, it's just that the bugs are different:

• Windows: it consumes the keypresses and the default behavior is broken
• macOS: it doesn't fire the callback for keypresses and enter/esc is broken

You can script the label entry yourself

HiseSnippet 824.3ocsUssaSCDDc2zZTsghnR7ArJOkHppR3tTUgPSaPQ8VDApJOg1rdS7Rs2Mx651FgpD+M76wePYVamXGHbQQT+fkm4Ly5im4Li6EqXbsVEivtuexXNBeOm9Sjlf1ATgD0cOD99NGQ0FdLIy0tSFS0ZtOBiW4sVGX2UQoWe+06RCoRFuvEBcpRv3GJhDlBu8ZcfHLrC0m+dQToneZqtLkrsJTk.7YEmFnwT14zQ7io1vp3fv2YeegQE22PMbMBu5tJ+I8CTWJyh+TgVLHjaMZh5CGTl6NpPeKisdQsCDg98l9cqQvozqnJrRVU3gNGI7Ey7WTMdPJ.oHix0Cbk4o2JyQulkoWiRzaATBWhRqlQoMb5yhEiMEHV9bWmtRn4LjBk8xTIKVTkugcZqfHjlshnmy6DCFyxn1yazXSBbq91ddPoWaHGRGvCaR1gLMqQbSaUzXkDLpUMCtJDe1SaosvRcRD2+.9jdw.y35ZUogg1fJE0Tz1.z.nsVaXhjYDJYM0fOW26KdthgD6yaIzcTrDMTyki3jc1gLjFp408bgXbKNvZUM7qLU2LmxVhl6pN4QD6AwBnwTF7sVeahm60dWWe6ouThRdrxvOQVK8U6csG4mgFNbgX15RrJLjGuPXqhN9OkXMYRz.d7ljKngI7YABs440NN+dsSYoMKqMUJPkrqTXNYLW96D7n7dK7zG5tG0PsBtbePbi4wFgkB383W.SuYxOWm835yMpwowlKHP30LonqmKNS6EHAHAWyIquftpX.+islLy3qm15RguIXlCxksB3hQAkVT7pV19Y5j+fQS2K3dmyN6raxVj7KCIv3oxOIjZlel0tnJG.ZFyMnXGFjZgYR4EY+2Fj+Wo3FN8DFVvh4XkEvQnkcavw70eq6r+vgbloffq5z4ramccn2oRLB4ninlXAHVbNNIpOzoYb6F.IOzNLfqXksY1Mr11JPetzO03F3JGro0FmC1bJHJhxhUehkMBZWvtVpGfSxz+s3B+jCrIMQoikkqyQv99OwXyeT+RhOdYS7IKahOcYS7YKahOeYS7EKahu7umn82wuIwnhxFaPni5se5NMLdeIETfopUzO.fQW1UF

But clicking on it will still make it go into edit mode and you can't query mouse selection of a string, so you're best of scripting the whole thing yourself instead using a panel, or just hope that this can get patched soon.

[d.healey]

Bump bump

[d.healey]

@Christoph-Hart Any chance you could take a look at it this?

[Christoph Hart]

@d-healey Hmm, the way that it worked previously was because the code wasn't precise. Key strokes are supposed to be consumed once used and from a API perspective I think that it's a valid behaviour as is (if you tell it to consume all keystrokes, then it will consume all keystrokes).

Have you tried the updateWithEachKey property? That makes the callback fire (with a small delay to avoid spamming the callback execution for fast typers) while you type so you could implement a dynamic search (or whatever you have in mind).

[Christoph Hart]

I mean we could add a special mode that is triggered by something like

Label1.setConsumedKeyPresses("all_nonexclusive");

which then returns false so that the keystroke can keep traversing the component tree.

[d.healey]

@Christoph-Hart I think the main issue is that it seems to respond differently on each OS, as Aaron wrote above.

[Christoph Hart]

@d-healey Ah ok, I need to check it on macOS then, but I think that's because the label gives the keyboard focus away to the OS for native text input on macOS (I think that's because it shares some code with iOS where the onscreen keyboard needs to appear).

But that proves my point. Messing with the keyboard focus of a text input is not the best solution, and I would recommend switching over to the updateWithEachKey property (I'm using this in Triaz to update the search results for the sample browser while typing).

[d.healey]

@Christoph-Hart said in Return the old Content.setKeyPressCallback functionality (that we had for a few days):

I would recommend switching over to the updateWithEachKey property

If I enable this property I get no text appearing with Aaron's snippet above.
Oh I just figured out what you meant. Use this instead of the keypress callback, yeah that seems to work.

Without the setting enabled I still have some issues.

-- When I start typing the blinky cursor disappears.

-- I have to handle backspaces and delete manually with code like this

  var text = Label1.get("text");

  if (obj.keyCode == 8 || obj.description == "backspace")
    Label1.set("text", text.substring(0, text.length - 1));

Could you provide an example that gives the behaviour we had before this change was implemented?

[Christoph Hart]

Without the setting enabled I still have some issues.

Then enable it. As I said, entering text should not be implemented manually and the callback should only be used for shortcuts / triggering actions.