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

[d.healey]

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

@d-healey I opened your snippet and can type into the label. Click on label, type, works as expected.

macOS 14.4.1 9d0b36cc0e5c4dc9d5c5bc3f434323322fa13fe1

Confirmed. Seems to be a Linux bug. I'll see if I can figure it out.

[d.healey]

hmmm I can't see anything obvious and no errors reported in the debugger. @Christoph-Hart Any ideas?

[d.healey]

@Christoph-Hart If I remove the return true from here it works - https://github.com/christophhart/HISE/commit/65ef5cbdb6b6a28210afd961fa8ebbf7e6a9f7e0#diff-0d582ddb8fc1bed436b29e85947f1c794dabe03de8eba02b4632e41563e4187dR1609

But I'm guessing I shouldn't do that?

[d.healey]

@Christoph-Hart Bump bump

[d.healey]

@Christoph-Hart Still having this issue on Linux

[d.healey]

@Christoph-Hart Seems this isn't just a Linux problem. Try this snippet on Windows

HiseSnippet 768.3ocsU01SaCCD1tsAQ6FSCo84oH9TQBgZ2XuHglVG8koJnP0JC08IjahaiGN1QIN.USHsex6e.6bbZS5nCXUZ4CU4tm6re5cO2k9gRGZTjLDgKe5z.JB+TqASEJuldDl.0sEB+LqdjHEMz135foAjnHpKBiK9YsCb4Rnjme8wCHbhvgl4BgNSxbnGw7YpLu8abHiy6Pbomx7yE8dM55HEMkbYLvmhV0PADmKHSnGSzgUvBgWqsKSICGnHJZDBW5.o6zAdxqDl3OiEwFwoZi5nAvAYb2Qxc0LV6E0ziwc6O6+cDBNk9YUghlpvKr5wbYy8mUMddBfcVF4qG3BKRuhKPu5+M5sDJgyQoRFJso0.mPVfJCQymmX0U.MmwDnrmmJlXQE5fsZJgHDpc8IWP6DBFyyn5aqUaGa3ms2uREnzGorOhLhxqa+A6YYMgpZJ8CjBvn5VF3sf3MusajFVDE6ScOjNseHvLZT0sHbtNnbQMCsI.MBZqUGGKbTLonpbz22txOpT4ls2elOao3XohdhnpFobkapX+mPiGuTLMsCkbNMbovZAW38kXUQr+HZ3N1WR3wz4ABcgEasq83ZsNlpXt.khtBl5j.Zp88qMQosA3su1sEQQzZiTePbAzPESSGbK5kvflQoT1pEM5BkLHI1zdGButJAciTcTRqAwfqdcKSaBcc1r32ZLctwOOqwULWkGBagCwHjGkMwSosdIfpnWqRFNGMY1na40FNb3slY86nigIHoaLmnVbrRuKIE.ZHKnk05UQDSMM+tl+gYsZ26r1ikhaZ0mob7VNGKrDNBsp+GbLcC0FVsGOl5nxHXIqNCW00QOv0+EYrhIlzinBYfHw53X+APm1gB2tPP4QZwPAsb0XWSaqq.CnB2DiagmTv5ZabJX8YfHehSn7bGyXndG35Id.NIRV+WF9NDXaWGkLZluN6CqjO2wYwi5NI9pUMwWupIt2pl3aV0De6pl36V0De+Cmn9KleJVI8MiMHTu9sS1kgwsEDPAlnVQ+Ff5Dq0.

I see the relevant HISE source code has changed since I initially reported this issue, so possibly the changes have made it broken for other OSs now :)

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