I’m wondering if there’s anything in the API that will allow me to call a callback function when the entire editor loses focus (i.e. I switch tabs to a web browser, or I minimize Sublime Text), and conversely when the editor regains focus. I know that the old API had activeWindow().hwnd() for Windows, but the current API (https://www.sublimetext.com/docs/3/api_reference.html) doesn’t seem to have anything like this. The closest thing I see is on_deactivated_async, but I’m not sure that works for the entire editor, only a specific view. Has anyone else tried to solve this problem before?
Sublime callback function when editor loses focus?
OdatNurd
#2
I haven’t come across anything like this than I can recall, no. Note that window.hwnd() still seems to be there and return a value even though it’s not documented:
>>> window.hwnd()
4326566
Some experimentation seems to indicated that the activated and deactivated events only trigger when the associated view loses focus to another view but not in general.
0 Likes
There’s atleast a comment in the sublime.py file that window.hwnd() is for windows only & returns a meaningful result on windows, though what that number represents, I can’t imagine.
0 Likes
OdatNurd
#4
HWND is a Win32 API Window handle; if you will it’s the unique value for any particular window that uniquely identifies it. Technically speaking I think it’s actually a pointer to some internal data in the core of windows, but it’s been a coon’s age since I did any Windows programming and my recollection on that is a bit hazy.
Basically, if you wanted to interface your plugin with native Windows code (say using an FFI like ctypes), you could use that value in Win32 API functions to work with the Sublime window.
I’ve played with that a tiny bit in the past, but on the whole I’m not super interested in doing anything in a plugin that only works on one platform because I use Sublime on all of them, so I’ve never really dug into it in any detail.
I suspect that there’s not a way to generically determine when Sublime has lost the input focus without either more events being exposed or (for windows) going the route of an FFI, though I may be wrong.
1 Like
FichteFoll
#6
I meant to suggest a solution that listens to both on_activated and on_deactivated with a small timeout in between to track state, but that fails when looking at the sidebar or any widget/panel, since those will also cause all main views to lose focus.
0 Likes