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

[d.healey]

Can someone try the snippet above and confirm the issue? Thanks.

[aaronventure]

@d-healey Can you please sum up what am I supposed to be looking for?

The snippet behaves like the last one on macOS.

I'm seeing something else, though: if the script callback exists, then pressing enter will not defocus the label i.e. it won't return to its passive/not-editing state, but the Enter/Return callback trigger will definitely go through and send the appropriate obj in the callback.

[d.healey]

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

Can you please sum up what am I supposed to be looking for?

Typing in the box doesn't do anything.

I just tested on MacOS and it's working fine there, so the issue seems to only be on Windows and Linux.

[ulrik]

@d-healey this is not working here on MacOS
the label callback fires only if clicking outside the label

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

I'm on commit

[ulrik]

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

I just tested on MacOS and it's working fine there, so the issue seems to only be on Windows and Linux.

Which commit are you on?

[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).