Non-responsive dialog

I am porting a mixer application I have written in windows to linux (ubuntu 14.04 from kxstudio).  Much of it works, but I have one weird problem.  I have dialog that is basically a channel strip.  It used as a channel strip both on input channels and for master mix outputs.  By default 3 dialog windows open, master, mix and channel strip.  Select buttons one each channel update the channel to refect settings for that channel.  If I close the display the buttons will open it.

I use the same idea for the master but the dialog is not open by default.  If I click the selection it opens the dialog, but it does not respond to anything.  No mouse actions do anything.  I cannot even move the dialog box.  It is like the dialog window never gets focus.   I am using eclipse to debuf and I can breakpoint but if I set breakpoints in button click or slider change methods, I can see they never get called.

I am not sure how to start debugging this.  Any suggesstions?


PS.  It works as expected in windows.

Did some more experimenting with no progress.  I a guessing it has something to do with the fact that the maincontentcomponent window opens the first 2 dialogs for channel strip and master.  But this dialog is opened from the master, so it is a chld of a child.  When the window opens it comes to the front.  No buttons or knob respond to mouse clicks.  But if I bring something else in from, the click this dialog it gets focus and comes to the foreground.  The odd thing is that even the close button in the upper corner does not work.  So where do the mouse events go?

Don't quite understand what you mean, but is it just that you're making these windows modal?

Not modal. 

Sorry if I was unclear.  My mixer application has 4 main window/dialogs.  There is a maincontentcomponent window contain a mixer view with channel volume and buttons for inluding channel select.  There is a master window containing volume controls for busses and auxes with buttons for each including buss/aux select.  Then there is a channel strip with eq-compressor-gate controls.

When the program starts, the maincontent view is displayed it's constructo creates a the master window and a channel strip.  If a select buttion from the maincontentcomponent window is pressed, the channel strip changes to the selected channel.  If the channel strip is closed and the select button is pressed, it reopens the window.

There 4th window is also a channel strip but is is used for auxes/busses but is not open at startup.  If you press the select button on the master, a channel strip is opened for that buss or aux that was selected.  This is the box that does not get mouse events.

I was wondering if it was because is was started by the master section that was start by main.  I just don't understand why the addMouseListener doesnt seem to work for this.  The close button on the frame should work even if I don't setup a MouseListener, shouldn't it?  The fact that that does not work makes me think is has nothing to do with the addMouseListener but something else.

Too much detail to absorb it all! But the order or time at which you create windows doesn't matter, so I'm really not sure what to suggest there. If I was debugging it myself, I'd stick some breakpoints in the mouse-handling code and just see what happens.

Ok, Did some breakpointing and found that things go wrong in juce_MouseInputSource.cpp:202.

            if (Component* const current = getComponentUnderMouse())
                registerMouseDown (screenPos, time, *current, buttonState);
                sendMouseDown (*current, screenPos, time);

The getComponentUnderMouse returns 0.  On the dialogs that works andthe sendMouseDown is called.

I solved the problem though I don't understand the this behavior.  After I created the dialogwindow, I set it invisable.  The constructor of the window created a dialog and set it visible.  Maybe you can explain this Jules.  The window was invisiabel, but the dialog within was visable.  I could see the window, but it did not respond.  It seems like I should not have been able to see the window.

No idea, TBH.. Could be something going wrong in the linux windowing stuff, but I've not heard of anything like that before.