Windows - witching between apps


#1

Jules, can you fix this very annoying problem that my testers are complaining about.

In Windows, if you have a MainWindow and then open a DialogWindow, switch to the desktop, and then try to activate your app, only the DialogWindow appears, not the main window. This happens in the demo and in Tracktion. There is now way to make the Main Window appear except to close the dialog.

Also when you switch to the desktop, the taskbar shows the main window and the DialogWindow. It should only show the main window. Juce is the only application with this problem.

 


#2

Well it's not really a "problem".. The window you call your "main" window isn't special, and isn't connected to any other windows that you create. If a dialog is brought to the front, how would it be supposed to know that you also want it to bring your other window(s) to the front? What if there are many windows, should it make them all visible even if they're hidden? There could be many cases where you don't want a dialog to mess about with the visibility of other windows which may be hidden deliberately.

Something I've meant to do for a long time is to come up with some kind of z-order enforcement system, so you can set up a relationship between a number of windows and have it keep them all in a stack, and that'd probably be what you want here.


#3

Well it is a problem in that I am already getting complaints in testing, and Juce is the only enviroment this is happening in. Can you imagine when 30,000 people get their hands on this and start complaining. The simple fact is that when an application is made inactive the application should return to this state when it becomes active again. Look at the iOS requiremtns. This is part of the whole iOS enviroment, in that application should maintain their state when switched in and out. Also the Dialog should not be shown as a separate window in the task bar. The Dialog is a child of the Main app. I am embarrassed that this is hapenning. It make my/juce apps look amateurish.

PLEASE fix this. If I knew how I would fix it.


#4

If this behaviour is so crucial to your own app, then maybe it's something you need to handle yourself as a special case on Windows?

It's no good saying "it works like that on iOS".. iOS and Windows handle this in completely different ways, and your original question is about MS Windows, right? In iOS/OSX all of an app's windows are shown/hidden as a group by the OS itself, but on Windows, the OS doesn't do that, and it's left up to your app to decide what happens to each window.

If you really need to make your main window follow the visibility of another one, then you can just use a ComponentListener or other mechanism to respond to it being shown/hidden.


#5

Maybe you don't see it.

In Windows,

1. RunTracktion,

2. Click on the Open Project.. button.

3. Right click on the task bar and choose Show Desktop.

4. Click on the Trackition icon in task bar.

5. "Only the Open Dialog shows."

5. Click Cancel.

7. Where is Tracktion? It is not there, You have to click on the icon in the task bar, again.

This is just unacceptable.

 

 


#6

Sorry, but I'm struggling to understand why you're getting hysterical about something that IMHO is a total non-issue.

Can you imagine when 30,000 people get their hands on this and start complaining.

Yes, I can imagine that, because we have more than 30,000 tracktion users who complain loudly every day about everything imaginable. But so far in the last 10 years, the number of complaints about this is.. zero.

 

Maybe your app is different - perhaps it involves constantly minimising/maximising with lots of dialog boxes open for some reason? If so, just do what I suggested and add a bit of logic to make sure all the windows remain visible in whatever way you need them to. Not a big deal, surely.

And can other people please give some perspective here... As far as I'm concerned, I really couldn't give a fuck about this - it's just the way windows behave in MS Windows. Whereas you seem to think it will destroy your professional reputation and ruin your business. Who's right?


#7

I will say that I've noticed it happen in my tools... but I definitely have not cared about it. It's something that I could easily fix if I wanted to (as jules described)but I have never felt the need to.


#8

Sorry, I have to agree with Jules. Although it is nice to have consistency amongst OSs, I think it is inappropriate for JUCE to force applications to behave in non-OS specific ways. For one thing, which OS does the "right thing" ?

 


#9

Personally I actually prefer to have each Window appear separately but maybe that’s because I mainly use OSX and much prefer its process/windowing model. The behaviour you’re describing would be completely out of place in OSX, imagine if you minimised one Finder window and they all closed? There is a clear, separate behaviour for this, to hide the process.

While I can appreciate everyone has different preferences and you obviously prefer the common Windows approach you can’t expect a cross-platform framework to enforce OS specific behaviour like this. There may be many cases where you have a true multi-windowed app on Windows where each window needs to be shown/hidden independently. The fact that your are showing the window modally is totally up to you.

DialogWindow is really just a quick solution to show something in a Window, if you have more specifc needs you really need to implement your own custom behaviour. Really, how long would it take to copy the contents of DialogWindow and set the ComponentPeer::windowIsTemporary flag so that it doesn’t appear on the task bar and then add a listener to your ‘main’ window so that it mirrors its minimisation state. Probably less time than writing this forum post.

Honestly, constantly demanding fixes for ‘bugs’ which are really feature requests or behavioural preferences is getting a bit tiresome. Maybe you should spend a bit of time writing these classes yourself and then releasing them under the GPL for everyone to benefit?


#10

Obviously you all have not tried what I suggested above with Tracktion on Windows. Try it and you'll see the problem

When you switch out to the desktop on a OSX, the main application windows does not disappear. So when Tracktion becomes the active window again, so there is no problem. I have been a cross platform developer for over 30 years, and this behavior on Windows is just incorrect. You can not igonore this. If the excuse is that Juce is a cross platform enviroment, then juce apps should not disappear when another app becomes active.

Just think if your OSX apps were disappearing when you switch to the desktop and when you came back the app was no longer visible. You would be screaming to get it fixed.

And I can not write a quick fix, because I use the Native File Open and File save dialogs and the problem lies with Juce's incorrect design. The whol purpoase of using a cross platform enviroment so you don't have to worry about the native stuff. The enviroment is supposed to.