Mods could use an API to know if their window got focus.

[Dunbaratu]

As of version 0.10.13 and up, there are now two different places where focus follows Click exists, and they don't agree with each other, and both are visible to the player:

I am referring to these two values:

• ClearInputLocks.focusFollowsClick.
• HighLogic.CurrentGame.Parameters.CustomParams<ClickThroughFix.CTB>().focusFollowsclick

Both settings are still visible to the player, and they disagree. If you click the button to change the value, the toggle on the difficulty settings screen doesn't seem to change to match it.

On a similar note, Is there an official "API" way other mods are supposed to use if they want to query CTB and ask whether CTB is currently in focus-follows-mouse mode or click-focus mode? I was using the CustomParams way to do it, but it broke when the button was added in v0.10.13 and I feel like it's not very future-proof for me to be peeking into a part of CTB's code that's not officially a public-facing API promise.

[linuxgurugamer]

Regarding an API, tell me what you need and I'll get something together. Regarding the values, they are different because it can be temporarily changed.

Off hand, I'd say the following might work:

bool FocusFollowsClick bool FocusFollowsMouse These two would be the inverse of each other, I like having the api call make sense

string FocusOnWindow Return the ??? of the window where the focus currently is, empty string if not on a window

[Dunbaratu]

Currently the only reason I read CTB's focusFollowsClick setting is because that was the easiest way to fire off the code I had already written in kOS that used my own similar flag. Although it's a bigger refactor for me to go with your last idea, in the long run it's probably going to result in smaller, simpler code in kOS so that's probably better.

But one idea might be instead of having the API call tell me which CTB window has the focus, it may be enough to have a call where I pass in the window ID I want to query for, like so:

bool IsWindowFocused( id ); // numeric or string ID - whichever you prefer.

That way mods just ask about their own windows, instead of being given information that refers to other mods' windows.

[Dunbaratu]

Essentially the problem is that the only place to reliably get the state of the flag as it stands at the moment is this flag, but it's marked as internal so I cant use it. (Thus the talk about "API"). Even just a public get-only property that revealed this flag's state would be fine by me as an "API", and it would free you to change the underlying implementation later just so long as this property still exists to access the new way of getting the answer - I just didn't want to violate access rules because you might have put internal there for a reason.

https://github.com/linuxgurugamer/ClickThroughBlocker/blob/86141a61197564573f7053ebd6ef7c8cee0c840f/ClickThroughBlocker/ClearInputLocks.cs#L21

[Dunbaratu]

I believe the actual issue has morphed since my original description enough that it makes sense to change the title. Now it's about the API, not that the mod "disagrees with itself".

[Dunbaratu]

Sadly I'm going to have to release a kOS version that doesn't actually fix the click through problem because I can't use ClickThroughBlocker without this API (or something else that gives similar info) in it.

I did find a way do deal with the secondary problem (ClickThroughBlocker activating both the windows' input locks when you click on an overlapping area two windows share). I realized I can figure out which of the two windows is the one on top by taking advantage of the fact that I know Unity calls the IMGUI window redraw functions in order from backmost to frontmost so I can use that to have my windows track which one is frontmost by what order their repaint routines got called. When multiple windows believe they "have focus", I can have each one grab "the baton" in order during their onGUI window repaint routines, and whichever one grabs "the baton" last is the one that was called last and is thus the frontmost of the ones that tied.)

However, without the API in the ClickThroughBlocker DLL everyone else is using, I can't release a version of kOS that uses that solution, as it would still require I clobber the user's CTB install with one of my own I've customized to have the API present - and that's just being mean to other modders to pull that trick.

[linuxgurugamer]

Just curious, why wouldn't the GameEvent.onFocus work for this?