FSUIPC steals Focus / blocks Input when Lua Script ran (FSUIPCv6 / P3Dv5.1)

[Fragtality]

Hello!

I've found a strange problem when FSUIPC runs Lua Scripts: it changes the Focus to the Sim and blocks globally (whole OS) every Input. I have to repeatedly click on something that either the Sim or any other Program can receive input again. It only does happen when the Sim is not focused. It does happen regardless if the Script is invoked by a FSUIPC Button-Mapping or externally called (e.g. FSUIPC SDK for C#).
The Script can be as simple as

local lightPos = "PSEUDO"

I did not notice it much while flying, just wondered why I sometimes have repeatedly click something in the Sim.
But now I'm writing an C# Application which constantly polls FSUIPC and some of the code runs a Script. This results in an effectively blocked PC, nothing reacts anymore. Key-Input does not help, since the Focus is directly stolen again.

Maybe this related to other cases?
https://forum.simflight.com/topic/91608-msfs-fsuipc-7-issue-with-os-and-sim-app-focus/?tab=comments#comment-554500
https://forum.simflight.com/topic/91067-p3dv51-simconnect-menu-window-focus-issue-resolved/?tab=comments#comment-551143

I've tested the Configuration Parameters from the second Thread, but they do not affect this behaviour. I've tested SetForegroundOnKeySend+KeyboardFocus both set to No and both to Yes. Also I've tested LuaTrapKeyEvent Yes/No (seperate).
 

Kind Regards,
Fragtality

[John Dowson]

Hi Fragtality,

which version of FSUIPC and which Flight Sim are you using? Focus handling is different in FSUIPC7 to other versions, as FSUIPC7 is a stand-alone application, so I need to know this before I can take a look.

If you can let me know, I will look into this and report back. However, I'm pretty busy at the moment, so it will take me a few days to get around to this....

John

 

[Fragtality]

Both latest Versions, I knew I forgot something 😅

P3D v5.1 HF1 (5.1.12.26829)
FSUIPC v6.0.12

[Fragtality]

I have moved the repeated Calls of the Lua Scripts inside FSUIPC it self (Auto loaded Script which uses event.timer) - so that they don't have to be invoked from the outside.
Roughly the same result, regardless if they are called via ipc.macro or ipc.runlua. Roughly meaning, that Mouse-Input to the Sim is still blocked, but not the whole OS and there is sometimes a chance to get some moment of control to at least gracefully close P3D.

Since I'm already inside a Lua Script there is no real need to call another Script anymore and I can mitigate this Blocking. Luckily this Bug/Effect is no Showstopper for my App anymore! 🙂

 

[John Dowson]

19 minutes ago, Fragtality said:

Since I'm already inside a Lua Script there is no real need to call another Script anymore and I can mitigate this Blocking. Luckily this Bug/Effect is no Showstopper for my App anymore!

But I thought your issue was when calling any lua script (e.g. your simple example)  on a button press? If you were doing that on repeat, that would certainly be problematic as the lua is compiled before being executed and then ran, and the repeat would kill the running thread and start this again... Best to use event.button directly for such luas, rather than by direct FSUIPC asignments.

Anyway, sorry for the delay in this - I've been busy working on the lvar WASM module. I can take a look at this over the weekend if its an issue, but I think i  need more details on what you are actually trying to achieve.

John

 

[Fragtality]

On 2/5/2021 at 8:11 PM, John Dowson said:

But I thought your issue was when calling any lua script (e.g. your simple example)  on a button press?

That is still the Case 😉
When P3D is open, go to (focus) another Window on the second Monitor, execute this simple script via Joystick Button Assignment - then the focus is switched back to P3D and the mouse-input is blocked. Sometimes for everything but P3D, sometimes for everything. It's more noticeable if I hit the Button a few times in a row (for testing purposes). When I repeatedly click or alt-tab (quantity depends on how often the button was hit) everything is back to normal.
This focus steal/blocking behavior is most noticeable when P3D is not focused. But I also noticed, this "something" happens even when P3D is focused. When I hit the Button a few times in a row while P3D is focused, any other window is blocked - the focus is instantly switched back to P3D.

On 2/5/2021 at 8:11 PM, John Dowson said:

If you were doing that on repeat, that would certainly be problematic as the lua is compiled before being executed and then ran, and the repeat would kill the running thread and start this again... Best to use event.button directly for such luas, rather than by direct FSUIPC asignments.

My first Impression was also, that this happens when the lua is started (or compiled). But I think it has something to do when the lua ends (just done some more testing as I wrote)! When I run a little Loop via Button Assignment (logs a Message, sleeps for some Seconds), the focus steal/blocking happens when the loop has ended. Regardless of where the focus (inside/outside P3D) was when this Script was started. When I "tail -f" the Log, as soon as I see "finished", the Focus is stolen from Notepad++ and I have to click multiple Times on it to regain it.
Here's the Code:

local ticks = 0;
while (true) do
	ipc.log("tick")
	ipc.sleep(300)
	ticks = ticks + 1
	if ticks == 15 then
		break
	end
end
ipc.log("finished")

 

On 2/5/2021 at 8:11 PM, John Dowson said:

Anyway, sorry for the delay in this - I've been busy working on the lvar WASM module. I can take a look at this over the weekend if its an issue, but I think i  need more details on what you are actually trying to achieve.

Nothing to be sorry for 🙂
What I actually tried to say with my last Post was that this Problem is not as critical as before - so look into it when it suits you best 😉 
And that it doesn't matter where a Script is started, because it can also happen with ipc.macro or ipc.runlua.

What I'm trying to achieve in special, does not matter anymore. Thanks to Paul I found a great Workaround.
I stumbled over this while programming a StreamDeck Plugin which communicates (bi-directional) with P3D via FSUIPC (and Paul's C# Client DLL) - that is what I try to achieve in general. Since a Workaround is found for the Goal to repeatedly run lua-code, this odd behavior is not a Showstopper anymore for the Plugin development 😃

 

So to summarize: There is certainly some strange behavior, it would be cool if it could be fixed, but it does not stop anybody from anything 😅

Kind Regards
Daniel

[John Dowson]

Hi Daniel,

ok, thanks for the detailed explanation. I'll definitely look into this when I have more time.

Regards,

John

[John Dowson]

@Fragtality I have just done various tests with a simple lua assigned to a button press, and can run this lua when any window has the focus, on the FS display or on my second display, and the lua is executed and there is no change to the focus and no focus issues, so I am at a loss why you are having such focus issues. Could you show me your FSUIPC6.ini file please.

John

[Fragtality]

Sorry for the late Answer, didn't get a Notification.

I've send you the inis via PM.

As reported, the problem somehow went away with a fresh OS/P3D Install and new/fresh Install of the newest FSUIPC Version (.13).

Regarding your Answer on the three Configuration Parameters (LuaTrapKeyEvent, SetForegroundOnKeySend, KeyboardFocus): These are not existent within the new ini File (currently in use in the new/fresh Installation). But the strange thing is, I only added/altered these Parameters in the attempt to troubleshoot the old Installation (and therefore old ini-File)

[John Dowson]

ah, I must have mixed-up your old/new files, sorry - nothing strange.
And, as I couldn't reproduce your issue, and now neither can you, I'll consider this closed.