Listbox bug

I have a listbox bug plaguing my development from years: <https://xojo.com/issue/28116>

Basically the Listbox.CellKeyDown event won’t fire when entering keys like § ± £ ß F1, F2, etc. and some more. This prevent me to filter the user input.

If someone else experience this problem and need fix, I kindly ask to put some Feedback points on it.
This is really important for me.

Thanks in advance.

§ ± £ ß and the function keys do work here in CellKeyDown (I’m on a Mac).

Weird, because the bug is Verified…
Did you try the example project linked in the feedback case?

No, just created a small project for testing. And I’m currently not on the latest version of Xojo.

Please try it if you can. The bug is there from years, so even an older version should show the bug.
Thanks.

Hi Massimo,

I have strange results here with my French OS X (10.11.5):

Function Key typing are handled by the OS as Sound, Light, etc.

I pressed fn + a Function Key (the way to get the Function Key as F1 thru F12 on my laptop) and get your report for F10 and F12, but for F11, the main screen “disappears” and let me see my desktop contents.

The values of the pressed keys (“below” the 1…0 digits) are displayed in the MsgBox.
F1: 63328… F12: 63247 (excepted F11 tha is trapped by the OS).

HTH.

[quote=269494:@Emile Schwarz]
The values of the pressed keys (“below” the 1…0 digits) are displayed in the MsgBox.
F1: 63328… F12: 63247 (excepted F11 tha is trapped by the OS).[/quote]

In the example, there is a TextField to show the correct behavior.
Then there is a listbox to try doing the same while editing a listbox cell and show the problem. Have you tried this or just the TextField?

Just the TextField. Not all typed “chars” goes into the TextField, but most shows the MsgBox.

The results (when Editing one Listbox Cell) is… Kahotic at best: I can get §èçà, but I get o when I typed ¨(umlaut ?)… I wanted to get ö…

fn-F5 displays the text replacement PopOver window… all other Function keys do nothing.

Yeah this problem has been a thorn in my side for 2 years now. It makes it impossible to stop people from entering garbage into a listbox.

Perhaps you should validate the input after the user has finished and alert them of errors instead.
It’s a little more user friendly anyway.

Yes, it doesn’t work with the current version of Xojo.

[quote=269578:@Tim Parnell]Perhaps you should validate the input after the user has finished and alert them of errors instead.
It’s a little more user friendly anyway.[/quote]

I don’t agree on this. If a cell is meant to accept number, I should be able to reject alphabetic chars.

Well, unfortunately there’s a bug causing you issues. For now it seems that’s the route you’ll have to take.

more weird … I cannot find a way to download the project “listbox_fkey.xojo_binary_project.zip” !

While CellKeyDown doesn’t fire CellTextChange does (at least for ß and §).

Btw there are keys which simply don’t show in the text, like F1, F2, etc. So this workaround is still a partial solution.

As I said, we need to act basing on what the user type, not on what’s in the cell text. That’s what the CellKeyDown() event is meant for. Once something changed the cell text it’s too late.

Let’s backtrack a bit: what do you want to do? Perhaps we can find an alternative.

We created a Listbox subclass handling a lot of stuff like casting the user input for numbers (integers and currency), dates and more, including popup menus and many other as well. It also format the cells depending on how we configure it.
This custom grid is actually used in our cross platform enterprise solution and already in production for 50+ applications and growing.

Other than preventing our users to insert invalid characters, we need to catch Fkeys to trig special actions. These Fkeys are part of the specifications and are already used in many other places, so they can’t be changed with something else.

Some of these grids do live database update while the user type, so the best way we found to prevent unwanted character is to catch them in the CellKeyDown event and only allow to pass what’s sensitive.
Handing this in CellTextChange is out of discussion due to what I explained above and other technical complications (yeah it’s a very complex solution).

I already investigated other possible alternative, but I found the side effects are worst of the solution, so IMHO the only way would be to have the CellKeyDown event working as it should. And it works on Windows, but not on Mac.

It works fine under Windows, not under Mac.

I really don’t get how you use a listbox for user input. Anyways. Having to change an enterprise solution is no fun.

Apps like TextExpander can listen to all keydowns. Like a keyboard logger. I’m sure that there a are Cocoa declares to allow this.