SlickEdit Product Discussion > SlickEdit®

activate_tool_window() activates SlickEdit when it is not the active window

(1/4) > >>

rowbearto:
I've been noticing lately when I'm in a terminal window in Linux and SlickEdit is not the active window that sometimes SlickEdit takes over being the active window. It can happen when I'm in the middle of typing in the terminal window and interrupts my workflow.

I think it is due to the SE macro/command: activate_tool_window(). In one of my personal macros after a timer it calls activate_tool_window(), but at that time I'm working outside of SE. I've also noticed SE taking over focus even when I'm not running my own macro, so presumable some of SlickEdit's own macros are running activate_tool_window().

Please look into if activate_tool_window() is making SlickEdit the active window - it should only make the tool window active within SlickEdit - it should not be causing SlickEdit to become the active window and taking away focus from a terminal window where I may be working.

I'm using 27.0.1 in Linux x64 on CentOS 7

Clark:
Try having your macro check _AppHasFocus() and avoid calling activate_tool_window(). Hope this helps

rowbearto:
Thanks Clark, but it isn't just my macros. I'm noticing that SlickEdit is randomly taking focus, I think SlickEdit internal macros are using activate_tool_window() or something inside of it.

I've had my own macros for 4 years and in previous SlickEdit when I called activate_tool_window() it never caused SE to take the focus.

I think using _AppHasFocus() is a workaround, not the real solution. I could change my macros to use it but SlickEdit's macros will cause SE to take focus when I don't want it to.

I think it would be best if could have the old behavior where activate_tool_window() doesn't give SlickEdit the focus, it only activates the window inside of SlickEdit - but not giving SE the focus.

Can you check if this has changed in SE recently? Could I get the old behavior back? It is annoying to have SE take over the focus when I'm in the middle of typing in another window - even when it isn't my macros and it is SE's own macros doing this.

Additionally if I use _ApphasFocus() to not call activate_tool_window() then when I manually switch to SE the tool window that I wanted to have activated won't be activated. So the workaround of using _ApphasFocus() causes another problem in that when I do give SE the focus the desired tool window won't be activated.

Dennis:
The second argument of activate-tool-window() is set_focus(), when you are calling it from a timer, you should pass in set_focus: false for that argument.

When SlickEdit grabs focus, can you tell what tool window gets focus?  That would be helpful for tracking the issue down.  Do you have the Preview tool window or search results tool windows auto-hidden?

rowbearto:
Dennis: Thanks for that tip. I changed my macro to put set_focus=false when I call it and that solves the issue and SlickEdit doesn't take the focus.

For SE macros (outside of mine), one instance where SlickEdit is grabbing focus when I don't want it to is here:

macros/se/search/SearchResults.e

in showResults() function there is a call to:

activate_window(orig_view_id);

This doesn't set the set_focus=false.

So if I start a long search from SlickEdit and I go to another window and do some work, when the search is done SlickEdit grabs the focus which I do not want.

I also call this showResults() function from my own macro (I'm presenting the results from "Language Server Protocol" clangd server in search results).

Indeed it is taking over focus when I don't want it to.

Is there a reason why the default value of 'set_focus' parameter in activate_tool_window is 'true'?

I would think the default should be 'false', SlickEdit should not be trying to get the focus.

My suspicion is that in older versions of SlickEdit the 'set_focus' was not working, even if it was set to 'true' SE wasn't grabbing the focus. But I think version 27 may have fixed that issue and that is why I'm only noticing it now.

I think the proper solution may be to make the default for activate_tool_window's set_focus to be false? But maybe that can cause other issues?

I suggest that SE team goes through all calls to activate_tool_window() and make sure set_focus is set to true only when you really want to get the focus.

Meanwhile for the showResults() function perhaps a hot fix could be created to call activate_window with set_focus set to false?

Navigation

[0] Message Index

[#] Next page