(bug) Igor Pro sometimes forgets the stacking order of the windows

macOS 10.15.7
Igor Pro 8.04

When I switch from Igor Pro (without closing it) to another application and then switch back to Igor Pro, the window on top that I was working on sometimes automatically moves backward, hiding behind other windows. This bug is more often seen if I save the .pxp file, close Igor Pro, and then reopen the.pxp file. This makes it difficult for me to find the window I was working on.

I tried to give Accessibility permission to Igor Pro in System Preferences > Security & Privacy, but the problem still exists. This bug was never seen when I used Igor 6.

How can I fix the bug?

You probably get a faster response if you write such bug reports directly to the support via email. Does this problem go away with the latest nightly build (make a proper backup of your Igor folder to be safe before overwriting these files): https://www.wavemetrics.net/Downloads/latest8/

Also, it is not clear when the problem occurs. First you say it happens when you just switch to another application, but then you say you see this more often after closing and reopening a file? Does this not happen always? Does it happen less frequent without reopening the file?

This may be also function of additional code you may be using. My own code does management of all open panels on compile, so they get reordered more or less randomly (for user) as they get rearranged. So on restart, panels order gets changed in my case.  It is penalty users pay for other advantages. Obviously, other code may be doing this with graphs or any other Igor widgets. If you use some package of tools from non-Wavemetrics source, this may be something to talk about with the author.  

In reply to by johnweeks

johnweeks wrote:

Do you use Spaces? Igor and Spaces don't get along.

Yes I do use Spaces, but I never move any window in Igor Pro to another Space. I tried turning off Spaces and then reopening Igor Pro, but the bug remained (recorded video below):

https://i.imgur.com/TgQFJK7.gif

I activated Layout0, hid Igor Pro, then reactivated Igor Pro, but Layout0 is no longer on the top.

I downloaded your animated GIF and played it in Preview, where I can view it frame-by-frame. Interestingly, frame 59, the first after you re-activate Igor, the layout window IS on top. Can you share the experiment file? You can send it as an email attachment to support@wavemetrics.com.

Well, having said that, I noticed that all your graph windows have the Info bars open. So I made a graph and showed the info bar. Then I made a layout window. I hid Igor using Cmd-H, the clicked on Igor's dock icon to show it. The graph with info bar comes to the top, as you report.

If I close the info bar before hiding Igor, then the stacking order is as it was when hidden.

In Igor 6 that "attached" window was achieved using a feature of the Carbon windowing system (remember Carbon?). That feature ("Window groups") didn't make it into Cocoa and was never in the Qt framework we use now. The behavior is achieved now using some pretty skanky trickery involving re-stacking windows when we get a window activation event. It is very delicate code...

I'll look at it and see if there is something that can be done, but debugging that code is difficult- the source debugger changes how things work with respect to activation events, so it has to be done with many debugging statements printing into a special debugging window instead. And the sequence of events upon activation of Igor can be quite baffling.

In reply to by isend

isend wrote:

(Oh and I am obsessed with the Info bars, so I cannot get rid of this habit even if they are the cause of this problem.)

Didn't mean to suggest you get along without them, we like them, too :) Just that it's tricky code that might resist debugging and fixing.

isend sent a file to support as requested. I see his problem using Igor 9 and OS X 10.14.6 (Mojave) so it's not a Catalina problem. Here is what I reported to isend via support:

First response:

Executing this command:

print winlist("*", "\r", "WIN:1")
prints a list of graphs in the stacking order from top to bottom. When I first open your experiment file, I get this:
  Graph7
Graph6
Graph1
Graph5
Graph0
Graph1_1
Graph0_1
Graph8
Graph2
Graph3
Graph4
After doing the hide/show thing, I get this:
  Graph0_1
Graph1_1
Graph0
Graph5
Graph1
Graph6
Graph7
Graph8
Graph2
Graph3
Graph4

The graphs with no attached windows (info bars or tool palettes) are in their appropriate positions at the bottom of the stack. The windows with info/tool bars are not just not in the original order, they are reversed. If I do the hide/show thing yet once more, the order is the same as in the second list. This all suggests that my suspicion is correct, that it is the fault of the way we implemented the grouped windows. If we were still able to use the Carbon system, it wouldn't be a problem. But that was a long time ago...

That might be sufficient clues to figure out what's going on and to fix it. Maybe. As I said in my post that you referenced, it is delicate and kludgey code. I'm running out of time today, but tomorrow I will be investigating.
 

Then, after some work trying to figure out what's going on:

I have spent quite a lot of time over the past few days investigating this problem. I have found that a particular Qt window attribute used with tool palette windows, info windows and exterior control panels is somehow implicated (nitty gritty: it's Qt::WA_ShowWithoutActivating). Curiously, exterior control panels have this setting and don't cause the bad behavior you are complaining about, so there is some combination of... something... that I haven't figured out. The code involved in the two cases is complex and very different so it's not just a matter of seeing that we do something in one case and not in the other.

I considered the possibility of removing that setting only from info windows and tool palettes, but that alters the activation/deactivation of the owner windows in ways that might affect window hook code. It is simply too late in the release cycle for Igor 9 to risk such a change.

The good news is that this re-ordering effect only happens on the first time you hide/show Igor, as long as you don't hide/show any info windows or tool palettes. Small compensation, eh?