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

[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?

[rowbearto]

Just took a closer look at showResults() and see it is calling "activate_window()" and not "activate_tool_window()".

Still the search results is making SE grab the focus when I don't want it to.

How to fix that?

[rowbearto]

Perhaps the activate_window() function should not have SE grab the focus, but only activate the window within SE withing having the entire SE grab the focus?

Looks like activate_window() is a builtin so not hot fixable?

[rowbearto]

I tried a long search and at the end SE didn't grab the focus.

However my macro which calls showResults() inside of SearchResults.e - that does seem to grab the focus, don't understand why?

Also shouldn't the default value of set_focus in the call to activate_tool_window() be false and not true? I see many calls to activate_tool_window() in se macros without setting set_focus to false?

[Dennis]

There is an active_tool_window() deeper down the call chain in showResults().  I can put in a fix for this.  Thanks for the specific test case, things like this are really difficult to track down without some starting point to reproduce it.

[rowbearto]

Thanks Dennis.

That will fix this instance, but what about others? I recollect SE taking focus other times but I wasn't looking out for when.

Maybe the best solution is to change the default of set_focus in activate_tool_window to false?

Otherwise we are going to end up tracking down many activate_tool_window() that are setting the focus?

[rowbearto]

I made a local patch to toolwindow.e to make the default of set_focus to false in activate_tool_window().

After this patch the showResults() was still taking the focus! Don't understand why?

[Clark]

There is an active_tool_window() deeper down the call chain in showResults().  I can put in a fix for this.  Thanks for the specific test case, things like this are really difficult to track down without some starting point to reproduce it.

I don't think you can fix this issue. My tracing indicates that showResults() only calls active_tool_window() if the Search Results tool window isn't displayed. The act of displaying the Search Results tool window will give SlickEdit application focus.

[rowbearto]

SE seems to take focus when I haven't used my Linux desktop for a while, such as when I come back in the morning. I made a terminal window the focus and soon after starting work in the terminal window SE grabbed application focus. All I did was try to type in my terminal window first thing in the morning then SE took application focus interrupting my work.

It seems familiar like this has happened before.

Maybe SE noticed my mouse moving over it or it noticed it lost focus (I made the terminal window the focus, maybe SE had the focus before that?).

[Dennis]

Just to clarify, are you using the Qt4 or Qt5 edition of SlickEdit for Linux Intel?

[rowbearto]

I'm using Qt4. The Qt5 version isn't available on the "Registered Products" page. How to get that? I think I'd rather use Qt5 anyway.

I'm using Linux x64 on Intel.