I am using the keyListener plugin and get weird text field behaviour in list view.
As soon as I start typing the field loses focus, so I cannot enter more than 1 character in the field.
Sample solution reproducing the problem is attached.
I have another example of weird behaviour when the field does not lose focus, but whatever I type in the field with a keyListener on it disappears the next second.
So unless I take the focus out and put my cursor in the field again, I cannot enter more than one character.
Cannot reproduce this one. The form is in the record view and seems to be the same as the majority of the other forms where the field performs as expected.
Well, maybe someone could give me a clue where to look for the problem.
But yeah, the first one seems to be a bug.
Please confirm before I log it in the support system.
You forgot to attach the sample solution. Anyway, I am pretty sure that the code which is fired by the keylistener is responsible for changing the field focus. You will have to try to avoid that.
You forgot to attach the sample solution. Anyway, I am pretty sure that the code which is fired by the keylistener is responsible for changing the field focus. You will have to try to avoid that.
Yep, sorry about that
Attached now.
Omar, we cannot avoid using the keyListeners plugin because Servoy does not provide a way to trigger onRecordEditStart when a record is in fact edited.
Clicking in a field is not good enough for our existing customers (at the moment they use a FoxPro app which caters for that, I think it’s called interactive change in FoxPro).
There has been a discussion here on the forum with quite a few Servoy users insisting on changing when onRecordEditStart fires, but Servoy does not seem to agree to change anything like that, so we’re only left with few options.
There’s nothing wrong with using the key listener but you have to be careful in the event handling not to disturb the edit process as you have experienced. What I did in a similar situation was to add a timer that is reset with each keypress and is triggered as soon as the user stops typing or pauses long enough (like half a second).
Even the application.output() command may be responsible for losing focus in your employeecode field. If nothing interferes with the refresh logic it will work as exepected.
I made a short example that simulates VFP’s InteractiveChange event. It bind’s a keylistener in the OnFocusGained and removes it in the onFocusLost. In the onKeyPressed event the keypresses are checked and the code responds as soon as the user presses Enter.
There’s nothing wrong with using the key listener but you have to be careful in the event handling not to disturb the edit process as you have experienced. What I did in a similar situation was to add a timer that is reset with each keypress and is triggered as soon as the user stops typing or pauses long enough (like half a second).
Even the application.output() command may be responsible for losing focus in your employeecode field. If nothing interferes with the refresh logic it will work as exepected.
Omar, I’ve removed the application.output() from the functions in the sample solution, there is no code in them whatsoever, but the field still loses focus.
Check it out, I updated and attached it.
If it’s not a bug then I just don’t get it. This is frustrating.
