OnPluginGetFocus, OnPluginLoseFocus behaving oddly

Posted by Worstje on Sat 12 Jan 2008 07:06 PM — 8 posts, 27,373 views.

Worstje Netherlands Sat 12 Jan 2008 07:06 PM #0

Simply put, they don't always trigger. Worse of all, they hardly trigger, except for the strange occasions where it goes LoseFocus\nGetFocus.

I have a simple Lua plugin, with stuff as follows:

function OnPluginGetFocus()
	world.Note("I haz focus.")
	HaveFocus = true
end

function OnPluginLoseFocus()
	world.Note("I no haz focus.")
	HaveFocus = false
end

One particular bit of output is that I got the 'I no haz focus' message a few times in a row.

Usually I have my world-window maximized, essentially only seeing one world. The strange behaviour appears both when switching between applications (clicks or Alt+Tab make no difference), but also when I put my world windows on 'floating windows' and switching inbetween the worlds like that, no matter whether I click or Ctrl+Tab.

And.. oi, I finally found the difference all the way into writing this post. If I click on the OUTPUT area, it works fine. It works horribly when clicking the INPUT area. Other areas only work when focus wasn't in the INPUT area when losing the focus originally.

Could this be fixed?

Shaun Biggs USA Sat 12 Jan 2008 07:23 PM #1

I know a few of those issues are from how Windows itself handles telling a program if it has Focus or not. I noticed this a while ago when I was poking around with wxWidget's focus tools, and tried it with a few other libraries. It's mostly just spotty for telling the program that it's lost focus, as you mentioned.

Granted, I might have done something to horribly screw up my tests, so don't go around thinking I'm the "Voice of Truth" here or anything.

Worstje Netherlands Sat 12 Jan 2008 07:57 PM #2

It's nice to know there is something similar.

Perhaps there could be a GetInfo() call added that does a hard check using the appropriate Windows API to see if MUSHclient has focus, and one to see if the current world is the one with the focus? I don't mind changing from a push strategy to a pulling one. :)

Nick Gammon Australia Forum Administrator Sun 13 Jan 2008 05:30 AM #3

My preliminary analysis of the code is that there is a bug in the way the plugin callback is called. It seems that it might not be called if the focus is on the command window (or vice-versa).

It might be interesting to run your test with the *world* got-focus/lost-focus callbacks giving a note, as well as the plugin ones, and seeing if they differ.

Worstje Netherlands Sun 13 Jan 2008 02:59 PM #4

I just did your test, Nick, and it seems there is no such bug there. I can click both input and output area, other parts of the window, both in the case of switching to other applications and to another world.

So I assume it is some kind of bug with the way plugins are handled in this case.

Nick Gammon Australia Forum Administrator Sun 13 Jan 2008 07:03 PM #5

I think then that I must have overlooked one place when adding the plugin handler. In the meantime you could use the world handler (the one that works) to generate an event that plugins detect (eg. BroadcastPlugin).

Worstje Netherlands Sun 13 Jan 2008 07:59 PM #6

I'll dutifully wait for the next version. I hate hacks and clumsy workarounds (effective as they might be!) but that is entirely a mental tick in my persona.

Nick Gammon Australia Forum Administrator Fri 22 Feb 2008 01:35 AM #7

Version 4.22, available now, should correct those problems.