Suddenly, I can't drag my top-most window!


#1

I made quite a few changes to my working program and now I get this weird behavior.

When the program starts up, I cannot drag my main window around. It’s just a regular DocumentWindow, nothing fancy on it. If I resize the window, suddenly it drags perfectly well.

Neither moved() nor resized() is ever called until I do the resize - neither is NSViewComponentPeer::redirectMovedOrResized(). In fact, I’m not even sure where to set a breakpoint…

I’m working in OS/X 10.6.8.


#2

Baffling! Can’t think of anything obvious to suggest… Does it have a native title bar?


#3

Yes, absolutely, using the Mac native title bar.

I’d be better off if I could at least set a breakpoint somewhere that might go off when I dragged the window and nothing happened - but apparently not. I can certainly get a breakpoint to trigger (after the resize), but then no matter how high I go up the hierarchy to set a breakpoint, I simply get nothing happening.

Strangely enough, the window has already been programmatically resized before I even see it.

The worst is that I’m working in a branch, and I can go back to the original code, and that doesn’t have the issue - but no obvious change stands out that could conceivably be causing it. Unfortunately, there are too many changes for me to authoritatively examine all of them; and I’ve put too much work into the branch to discard and start again.

I thought it might be a lock that I was keeping but if I was holding the Message Manager Lock, I’m sure I’d know in a moment as the whole thing refused to work :smiley: and surely my code would have to be running to encounter any of my locks…? Plus if I pause the code at this time, there are no apparently locks being held…

Bah! I’ll keep fiddling and no doubt figure it out sooner or later. FRUSTRATING as I’m in the last stages of this beta…


#4

No joy yet (though I’ve been doing other things as well).

It’s baffling - I can’t see how my program’s state would have changed by resizing it a little, but its window reliably won’t be dragged around until I resize it a tiny bit, and then it drags perfectly well.

It seems to me from setting my breakpoint at JuceNSView::frameChanged that I’ve pretty well ensured that it’s not that some event is being ignored, but that no event is being created in the first place when I try to drag the window around.

QUESTION ONE: What is it that generates these messages? Is some of that Juce or is it all in the OS? Is there somewhere in this stack that I could set a breakpoint?!

This is more or less all that keeps me from releasing my beta (except for some cosmetic issues) so I’m sort of eager to make some progress at least on this.

I’m going to do something horrible later today, which is to spawn off a thread that slightly resizes the main window after a few hundred milliseconds. I doubt this will do anything, as I’m already successfully persisting the size of the main window, so I know that I’m setting the size during the startup process - but perhaps doing it later will break the stuckness somehow…

But that’s not a good solution.

QUESTION TWO: if you were trying to get this effect of an unmoveable window, how would you do so, if you didn’t want to override moved and reset the Window’s size?

QUESTION THREE: In that last codepath, is there some obvious difference between “resizing” and “moving” the TopLevelDocument?


#5

Can you reproduce the defect in a small test app?


#6

Good suggestion!

A tiny toy app I tried earlier works fine. It’s not clear what’s a logical step between a toy app and my full app. Nor have I been able to graft my code onto other working applications have and them fail, though I haven’t tried hard.

Note that I have a “main” branch and “beta” branch. About 90% of the code between the two is exactly the same, and I haven’t had any algorithm changes with respect to my GUI anyway. However, the main branch does not have this behavior.

The toy app I made could frankly have more or less been made from either branch and so wasn’t likely to show the behavior. But it’s really not clear how any of these changes could have this effect, and I can’t apply “a few changes” from one branch to the other, the whole reason it’s in a branch is because there’s a discontinuity (I went to a much simpler data model).

Usually this is no issue, I either set a breakpoint or put some print statements in and slowly piece things together by deduction. And, usually I’m making such small steps that I can use bisection to figure out what commit introduced the bug.

Since the messages are apparently not ever been generated rather than being lost, I’m wondering where messages are generated in the first place.


#7

Small update: programmatically resizing the window has no effect, even if I delay for 20 seconds or so. The only thing that works is manually resizing the window…

I also disabled my overrides to moved() and resized() so apparently none of my code is called during either resizing or moving operations - but I still get the same effect.

And just for good luck I rebuilt everything from scratch. No change.

Oh, and I tried setting breakpoints in the same spots in the “main” and “beta” branch. No obvious differences - except that, before I resize the window, my breakpoints trigger in the main branch but not in the beta branch.


#8

You need to comment out the bulk of your code until the defect goes away, then start bringing it back little by little until it reappears.

Try commenting out the constructor for the top level window first, see if that makes it go away.


#9

:frowning:

That’s really a last resort. If I start shutting things off that way, fairly soon things simply stop working at all (for example, if I shut off the object model, the window doesn’t even come up in the first place.

However, I have made some progress after a lot of experimenting and have a repeatable workaround, although I haven’t managed to transfer the defect to a toy program.

What’s happening is that I construct the window as a 0x0 window at (0, 0) and then a little later set its true position and dimensions. This is exactly the same in the old code and the new code, but it’s looking like the difference is that in the new code the window is “displayed” for a few milliseconds as an 0x0 window, and then a data update comes in and resets the size.

If I simply set the Window to any non-0x0 size in its constructor, I never get the issue! And it’ll be pretty easy for me to have the window’s correct size in the constructor. I have a general preference for having almost nothing in constructors, and then setting everything through data updates, but I’m not anal about it.

Unfortunately, now it’s working, I don’t have time to really isolate what the issue was. My theory is that if you created and displayed a DocumentWindow sized at 0x0/0,0 and then moved and resized a little later from your program, you’d see the same phenomenon.