WND: Data entry with keyboard problematic

[NovemberUniform]

Hi experts,

due to lack of alternatives I'm using the WND library to enter data into my little lua plugin. I declared key events for certain keys, that are allowed to be pressed for data entry. Generally, it works as expected. The data goes where it should. 

But there is the problem, that the keys that I press to enter the data into the window, also trigger the action that they are assigned to (either by fsuipc or the the sim itself). This is not desirable, at least not in my case. 

I found out, that keys, which are assigned in the sim itself, always seem to "go through".

Keys, which are assigned in FSUIPC, show different results. Some go through, some seem to be blocked.

Is there a way to only allow the data entry into the window and block all other functions the keys might have?

Thanks in advance. 

[John Dowson]

10 hours ago, NovemberUniform said:

due to lack of alternatives I'm using the WND library to enter data into my little lua plugin. I declared key events for certain keys, that are allowed to be pressed for data entry. Generally, it works as expected. The data goes where it should. 

Note there is also a user contribution to get keyboard input via lua for FSUIPC7 / MSFS - see 

 

10 hours ago, NovemberUniform said:

But there is the problem, that the keys that I press to enter the data into the window, also trigger the action that they are assigned to (either by fsuipc or the the sim itself). This is not desirable, at least not in my case. 

I found out, that keys, which are assigned in the sim itself, always seem to "go through".

Keys, which are assigned in FSUIPC, show different results. Some go through, some seem to be blocked.

Is there a way to only allow the data entry into the window and block all other functions the keys might have?

No keys should go through to the sim if the sim does not have the focus - you should give (or acquire) the focus to your input window to prevent this. And I can't understand how some keys assigned in FSUIPC can go through, others not...could you please elaborate and perhaps provide an example.

Anyway, I presume you are using the event.key lua function to get keyboard input, no? If so, then if you look at the documentation for this function you will see the following:

Quote

Note that, by default, such key events are not trapped and are passed on to the FS. If you would like to prevent them from being forwarded, add the ini parameter LuaTrapKeyEvent (=Yes) to the [General] section of your ini file.

I am not sure how relevant this ini parameter is now (as FSUIPC7 receives keyboard input from the FS when the FS has the focus), but you could try that.

Otherwise, please show me your lua script and provide more details and I will take a look.

John

[NovemberUniform]

On 6/17/2022 at 9:30 AM, John Dowson said:

No keys should go through to the sim if the sim does not have the focus - you should give (or acquire) the focus to your input window to prevent this.

Hi John, and thanks for your reply. Well, the keys I also use in MSFS are not trapped. They trigger the functions they are assigned to in MSFS. That's also the case, if I add LuaTrapKeyEvent=Yes to the ini. I guess, if I open the window like this, it has the focus. The keys I press get added to the window text...

w = wnd.open("mywindow", WND_FIXED, 50, 50, 410, 220) -- (pos x, pos y, size x, size y)
wnd.show(w, WND_TOPMOST) -- window always on top

 

On 6/17/2022 at 9:30 AM, John Dowson said:

And I can't understand how some keys assigned in FSUIPC can go through, others not...could you please elaborate and perhaps provide an example.

It's difficult to describe. I found out, that part of the problem is the duration the keys are pressed. I discovered it by mistake. I have assigned (via FSUIPC Key menu) all the numerical keys of my keyboard (the ones above the letters) to custom event presets for the Fenix A320. Those keys are no longer assigned in MSFS itself.

If I run my lua plugin, the window is presented to me and asks me to enter numerical values and confirm with enter key. If I press the keys quickly, all is good. The keys are entered in the window and their assigned FSUIPC function is not triggered. If I hold a key for a longer duration, they also get entered into the window, but their FSUIPC fuctions are triggered on top of that. There is actually no reason to hold a key for a longer duration, but I will maybe release this plugin to a wider audience and it must be more or less fool proof for that. To make things more complicated, if one key was pressed for a longer duration, after that, even a quick press of other keys trigger their FSUIPC functions.

On 6/17/2022 at 9:30 AM, John Dowson said:

Note there is also a user contribution to get keyboard input via lua for FSUIPC7 / MSFS - see 

Thanks, I might have a look at this if there is no way to get the stability with what I've tried so far. I would gladly show you my plugin but I would prefer to send it with a PM. Is this okay for you?

Thanks!

[John Dowson]

10 hours ago, NovemberUniform said:

Hi John, and thanks for your reply. Well, the keys I also use in MSFS are not trapped. They trigger the functions they are assigned to in MSFS. That's also the case, if I add LuaTrapKeyEvent=Yes to the ini.

That is strange - I will look into it...

10 hours ago, NovemberUniform said:

I would gladly show you my plugin but I would prefer to send it with a PM. Is this okay for you?

Yes, please do - it will help me to see what is happening. Do that and I will take a look and get back to you, although it may take a few days.

John

[John Dowson]

I am puzzled by this though - could you check by explicitly giving your lua Wnd window the focus by clicking on it - or maybe giving FSUIPC the focus. Really, the LuaTrapKeyEvent should be redundant now that FSUIPC is a separate application. The only way MSFS should see key presses when FSUIPC (or one of its lua processes) has the focus is if this is done explicitly via a keysend control...

I don't think opening a Wnd window (and setting it topmost) will give the window the focus, as the focus should remain with the FS. I don't think there is an easy way to give a wnd window the focus.

Best to just try this. I also suggest you activate logging for Buttons & Keys and open the logging console window. This will show you what keys are being received from the FS (meaning the FS has the focus)  and which, if any, are being sent to the FS. I suspect that the keys are being received from the FS, but lets see...

John

Edited June 20, 2022 by John Dowson
Further info added

[NovemberUniform]

Hi John, 

here is what happened.

If I click on the window prior to data entry, neither the window itself nor the sim receive any key presses. Strange... 

If I click on the FSUIPC window prior to data entry, the lua window receives the correct inputs and the sim keys are successfully trapped. So this is good, minus the FSUIPC window... 

If I click on the sim window prior to data entry (or just don't click anywhere, same result), the lua window receives the correct inputs but the sim keys are not trapped and their actions are triggered. 

8 hours ago, John Dowson said:

I also suggest you activate logging for Buttons & Keys and open the logging console window. This will show you what keys are being received from the FS (meaning the FS has the focus)  and which, if any, are being sent to the FS.

I also tried this. I told you, duration of the key press has an impact on the way it is received. This is with scenario 2 (clicking FSUIPC window prior to data entry).

If I press the keys very quickly, only keyUp is being listed in the log as not programmed. If I hold the keys down for longer, the keydown is being listed repeatedly as programmed in FSUIPC keys options. If I then release the keys, their preset is being performed. I hope that makes sense. 

I will also send you a stripped down version of the lua via PM. It should run under any circumstances for you to try out. Working on it right now. 

[John Dowson]

17 minutes ago, NovemberUniform said:

If I click on the window prior to data entry, neither the window itself nor the sim receive any key presses. Strange... 

If I click on the FSUIPC window prior to data entry, the lua window receives the correct inputs and the sim keys are successfully trapped. So this is good, minus the FSUIPC window... 

Ok, this makes sense. The wnd window has no key event handler - that comes from FSUIPC. When you create the window/run the lua, the focus stays with MSFS. MSFS forwards the keys to FSUIPC which then acts upon them, feeding them to your lua scripts (event.key I presume) and anything else that needs them, such as assignments.
When FSUIPC has the focus, FSUIPC picks up the keys directly and does the same. So the only difference is that MSFS assignments are not triggered.

There is not much I can do about this. The only thing I can think of would be to add a new control that gives the focus to FSUIPC7. You could then call this at the beginning of the lua, and call the restore focus when done. This would prevent MSFS assignments being triggered, but not FSUIPC ones.

To prevent FSUIPC assignments being triggered, you should have them on modifier/shifts keys (e.g. ctrl+x+, shift+x etc), and use standard keys in your lua key events.

By the way, I'm not sure the shifts values in the lua documentation are valid anymore, and even if they are they should probably be updated. I recently updated the other key handling functions to distinguish between left/right modifier keys (as well as removing the windows key, as that shouldn't be used) and I should do the same for these. I will look into this.

44 minutes ago, NovemberUniform said:

If I press the keys very quickly, only keyUp is being listed in the log as not programmed.

So no keydown is being received. Strange. I will check that here, but if its not being received from MSFS, I'm not sure there is much I can do (except maybe ignore the key up if no down had been received.

48 minutes ago, NovemberUniform said:

If I hold the keys down for longer, the keydown is being listed repeatedly as programmed in FSUIPC keys options. If I then release the keys, their preset is being performed. I hope that makes sense. 

Presumably your assignment is on the keydown and not the keyup, no? The assignment should be performed on the first key press though, if that is the case.
It would be helpful if you could attach your FSUIPC7.log and FSUIPC7.ini files so that I can take a look.

51 minutes ago, NovemberUniform said:

I will also send you a stripped down version of the lua via PM. It should run under any circumstances for you to try out. Working on it right now. 

Ok. although I don't need this at the moment. Your log and ini files are more useful.

[NovemberUniform]

I sent you the files. I think the biggest problem lies in the MSFS keys not being trapped. Whatever the problem is with longer key presses, I can live with that. Just don't press the keys longer than usual.

In the meantime, I will have a look at your proposed alternative for ipc.ask(). Maybe it works better for what I need.

[NovemberUniform]

1 hour ago, NovemberUniform said:

In the meantime, I will have a look at your proposed alternative for ipc.ask(). Maybe it works better for what I need.

Well, this is essentially the same thing that I did. It won't bring me any further, I guess.

I then tried to create events for mouse actions to more or less dial in my values with the mousewheel, instead of typing them with the keyboard, but the events didn't get triggered. Is this a known issue?

event.mousewheeltrap("fMouseWheelScroll") -- event for mouse-wheel movement
event.mouselefttrap("fMouseLeftClick") -- event for mouse-click left

[John Dowson]

11 hours ago, NovemberUniform said:

instead of typing them with the keyboard, but the events didn't get triggered. Is this a known issue?

Not by me...I will check those functions here.

[John Dowson]

13 hours ago, NovemberUniform said:

I then tried to create events for mouse actions to more or less dial in my values with the mousewheel, instead of typing them with the keyboard, but the events didn't get triggered. Is this a known issue?

event.mousewheeltrap("fMouseWheelScroll") -- event for mouse-wheel movement
event.mouselefttrap("fMouseLeftClick") -- event for mouse-click left

I've checked these and the event.mouse* functions don't seem to be working at the moment. I'm not sure why - I will look into this, but it will be low priority I'm afraid so it may take me a week or so before I get time to look into this.

I will continue looking into the other issues you have raised...

[John Dowson]

Btw, you are using v7.3.5 - the latest and only supported version is v7.3.6 - please update.

John

[NovemberUniform]

Sure, thank you. 

[John Dowson]

I have tested your script here and it works as expected here...

Your issue, from your log, is that the keydown events aren't being sent from MSFS - I do not know why this is. Could you maybe check your script using a different aircraft, to see if its the Fenix that is interfering. I can't do much about it if the event is being sent...

There does also seem to be an issue with your key down assignment not being triggered when no repeat is set as the first keydown has the repeat flag set - I will check this further here.

 

[John Dowson]

Ok, I think I understand what is happening a lot better now.

First, the LuaTrapKeyEvent ini parameter is working, but this prevents the FSUIPC assignments on the key not the MSFS assignments. However, the default value is Yes, which is why setting it to this value has no affect. You can set to No if/when you don't want these keys trapped. MSFS key assignments will always be acted upon when MSFS has the focus, but not when the focus is elsewhere (including FSUIPC).

So your key down assignment wasn't being acted upon (or logged) as it was being trapped by your lua event.key functions. However, as you are only trapping the key press, the ley release isn't being trapped and your assignments are being called. If you want to prevent this, trap the press and release event (which you can then ignore in your handling function if you so wish). I think (but haven't tested) that this also applies to repeat key press events - if you don't trap the repeat, any assignments to a repeated key will take affect. So, to stop all FSUIPC assignments, you need to trap the press, repeats and release. As with releases, you can ignore repeats (or not, as you wish) in your handling function.

The shift flags are also incorrectly documented for the event.key function - they are the same values as documented in the Advanced User manual, page 25. I have also added 1 additional flag:
    +512 - trap key events
This can be used when LuaTrapKeyEvent is set to No and you want fine-grain control got each event.key assignment.

I have also added a bit more logging in the attached version (mainly for when keys are trapped) if you would like to try. It should be clearer what is going on using this.

John

FSUIPC7.exe

[John Dowson]

One other thing I will add and test is a new ini parameter TrapMSFSKeys - when set to Yes, this will request that all single key press events to not trigger MSFS assignments. This was not working in earlier versions of MSFS but I haven't tested this in a while. I will add and test tomorrow and post a new version for you to try if working. If not working, I will add a new FSUIPC control that will attempt to set the focus to FSUIPC (away from MSFS) so that key assignments are not triggered.

[John Dowson]

22 hours ago, John Dowson said:

One other thing I will add and test is a new ini parameter TrapMSFSKeys - when set to Yes, this will request that all single key press events to not trigger MSFS assignments.

I have tried this and it doesn't work - this only stops keys going to other lower priority applications that have requested the keys, and doesn't prevent MSFS acting upon them.

22 hours ago, John Dowson said:

If not working, I will add a new FSUIPC control that will attempt to set the focus to FSUIPC (away from MSFS) so that key assignments are not triggered.

I have also implemented this, but it is of no use. Key input is currently only being received from MSFS, so if MSFS does not have the focus, no key input is received.
I may look into keyboard input when FSUIPC has the focus, but this may take a while.

 

[John Dowson]

1 hour ago, John Dowson said:

I may look into keyboard input when FSUIPC has the focus, but this may take a while.

This wasn't so difficult... Please try the attached version. You should add the following line to the end of your script:
     ipc.control(1156) -- set focus to FSUIPC
This will prevent MSFS from receiving and acting upon the key presses. You should also add the following line before your ipc.exit() calls:
     ipc.control(1125) -- restore focus to MSFS

The other changes you should make, as explained earlier, is to register for release and repeat events by setting the downup parameter to 7, and modify your handling function to ignore releases and repeats. This will then prevent any FSUIPC assignments being triggered while your plugin is active.

John

FSUIPC7.exe

 

[NovemberUniform]

Sounds excellent. Your efforts are very much appreciated. I will have a look as soon as possible. 

[NovemberUniform]

11 hours ago, John Dowson said:

Please try the attached version.

I did, and with another addition, this is working fine now. With mouse clicks between or during data entry, MSFS could regain focus. So I put the line 

ipc.control(1156) -- set focus

in a event.timer(20, "callback_fcn") callback function, to keep the focus on FSUIPC during data entry. This works very good now!

11 hours ago, John Dowson said:

This will then prevent any FSUIPC assignments being triggered while your plugin is active.

Yes, 100%. Also, no problems with long key presses anymore.

I'm happy, and I can now concentrate on other parts of my plugin.

👏

[John Dowson]

👍