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

[aaronventure]

There were a few days earlier this year where the global Content.setKeyPressCallback behaved like the key press callbacks for components: it always fired and you wrote your logic by filtering through the obj. object.

Then a few days later it was changed to what it is today: it asks for keyPress and lets you define different callbacks for each keypress.

Could a functionality be added where we pass some string instead of a keypress string that lets it always go off on any keypress or focus change, like it did before? This would not break existing functionality.

There are a couple of issues with the current method. Repetitive logic needs to be defined separately. If any of these keys then does something else additionally, you have to manually define it all and can't just pass a single function like you can to all other keys. If you wish to iteratively add functionality, the creating and passing a broadcaster then adding functions to that broadcaster is the way to do it. Except now you need to call the method for every single character you wish to use and pass that broadcaster, effectively recreating the entire ascii table!

[Christoph Hart]

@aaronventure The problem with the old approach was that it required a script execution for every single key stroke, regardless of whether it is actually used or not. This lead to many stability issues because they had to be executed synchronously in order to tell whether the keypress was consumed or not.

The new way is now checking for keypress matches before calling into any script, then returns true if the registered keypress matches (all within C++) and kicks off the asynchronous script callback, which is much more stable.

But a catch-all string might work, but can you elaborate the use case you're after?

[aaronventure]

@Christoph-Hart Ah I get it.

The use case it defining navigation behavior for keys like ESC, backspace etc. based on flags (e.g. isSettings = true) without worrying about focus which is necessary to catch keypresses with the (currently bugged) component keypress callback.

In my case it's navigation but it can honestly be anything else. I'll try to implement a functionality where Right Click > Learn takes you to a separate screen where you can see all the mappings, and if you attempt to type here it'll start typing the controller number to assign to.

By manually gating functionality of key presses with flags, I don't have to worry about juggling focus and keeping track of the focus logic if/when I add new components, and no matter what changes I make, I just have to make sure a flag is set to enable desired keyboard functionality.

[aaronventure]

@Christoph-Hart Btw, what is it checking against? For special keys like Backspace, it works if you type in backspace no matter the case, but BS, which is the character code in ASCII for backspace, does not work.

[ulrik]

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

The new way is now checking for keypress matches before calling into any script, then returns true if the registered keypress matches (all within C++) and kicks off the asynchronous script callback, which is much more stable.

But a catch-all string might work, but can you elaborate the use case you're after?

Ok this broke a lot in my projects, so it says

Does this mean I have to list every character I'm going to use in the specified keypress callback?
like

const consumedKeys =
	[
	"a", "b", "c", etc........];

It is a callback for user search presets

Or how do I setup a "catch-all" string? (I guess this string will cover all

[aaronventure]

@ulrik you can do pass in cosumedKeys = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".split("");

and follow up with any special keys you want to use

consumedKeys.concat("Escape", "Backspace", "Return", "Delete");

[Christoph Hart]

@aaronventure Or just use setConsumedKeyPresses("all") :)

Throwing a compile error when you don't call this method is an entirely educational measure, but I think it's better if people run against a compile error that requires their attention instead of silently changing the behaviour (because here the implications are very subtle and not obvious).

[ulrik]

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

@aaronventure Or just use setConsumedKeyPresses("all") :)

this will throw an error
and the project will not compile

[ulrik]

@Christoph-Hart sorry, I opened it with an old compiled Hise app,
indeed it work, thank you @aaronventure and @Christoph-Hart !

[d.healey]

@ulrik New docs - https://github.com/christophhart/hise_documentation/blob/master/scripting/scripting-api/scriptpanel/setconsumedkeypresses.md

[ulrik]

@d-healey thanks David!

[d.healey]

Just ran into this myself opening an old project.

I have a label. When the user types into the label I want to perform an action based on the text that is typed. If I use setConsumedKeyPresses("all"); then the callback triggers but the text in the label doesn't change as the user types. Is this a bug or am I using it incorrectly?

HiseSnippet 753.3ocsUstSaCCE1tzvnciogzd.h3WEIDpciwlzDZL5koJnPzJCs+gbSbZ7picjsCP0Duy6MX63jTZKTwkJsnpJeNemujubtEOkzmp0REBW4rwITD9UN8GKLQMiHLApaKD90N8HZCU4l65vwIDslFfv3U9l0AtRYT10e9xgDNQ3Sm5BgNWx7oGyhYlod8N3HFm2gDPOiEOSz6dPWeonojKSA8rhScTBweDYH8DhMrRNH7psCXFopugXnZHlCkAi6GIuRjG+4LMa.mZMZf5C2nb2nlQLdf2j2UMBgK6M8Mek72725ziEvt0+zLvax.bmxX1b.tzCIoFOCIgmQRkykzFN88UrDyTDqddoSWATPBIPpdVojGKpzwXmlRHBgYmXxHZGEXbKiZ6Uu91tvea84pUgzs13dIQ4dLY.k2vce2ILGRMMkwIRAXTayb3MsbxOti1hKzowzfini8Tf7n5ZaR376D0Dzl.z.ndVKLU3aXRQM4fesU0eWs5M.gINckhSjF5ohZVnJUuop6cgBCWHlU3JImSUKD11podHh0DowCnpsgzAOkdafPsX9B7pOsBreddbl.khtBl4zDZgcGIOvV3rmue6.pnP.m9Q2VDCw1gT3ChKgpLLqbvsnWBiX48KUbZQ0iLxjrXKpdH7KLYnqWzMkUaPL3QulSdcBcMB6fOBdVisG1GNbEKvDYM1FiPQT1vHi0xCfLzqM16lNHr3WHLTeulWXrQFjxIl4mkrKMJ.f7+bMv1lTglYFO6Rkmw.V8Gb.6oJwMb7XF+nEqwRKPiPk4+gFKVKstS6vPpuYp.K6z4mK6NnG4w+cYpgIF1iXTLaOwIow8gsw9T3oKDTt11CTx1claW2Zay.8ohfLi+BWEfMr13BvFS.QwDek7B+7oN6hu0x7.ZRjsmuB7AGv1sAJaRb17bLrG9Be+4uU2i36VVhueYIt6xR7CKKw8VVhebYI9oGmn8yjeM0HiyGaPnddsyVcgwsEDnCLqaE8OvbAXk9

[aaronventure]

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

macOS 14.4.1 9d0b36cc0e5c4dc9d5c5bc3f434323322fa13fe1

[d.healey]

@aaronventure Time to fire up my Mac and see if it works there

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