MediaMonkey forum

Hi,
I wanted to post this time ago, but it's never too late.
I notice that, in MM, windows and 'sub-windows' have not that kind of priority they shoud have. For example, in the 'options' window you usually open new windows or dialogs to configure some plugins, etc... It's extremely easy that this sub-windows (if this name exists) or dialogs 'disappear' if you click, let's say, somewhere out of the dialog itself. But they don't really disappear, they just go behind all the opened windows. So, since these dialogs have no notice in the taskbar, unless you know what's happening you would think that MM is dead cause you cannot interact with it while other dialogs are opened (and they are, in the bottom). When you finally close MM (from the tray icon) you realize what was 'freezing' MM, seeing the small dialog popping up and closing together with MM.
And also if you knew what was going on, it's not pretty to go and look for that lost dialog.
Without further ado, please set windows and dialogs to be always on top, when the MM window is on focus.
Have a good day.

I've noticed this as well and it is often difficult to get the dialog sheets to come to the front in order to work with them. I've seen this happen often if you've shifted the focus from MM after opening a dialog.

Nyn

This bothers me too. It seems that only non-MM windows (MsgBox or CommonDialog) have such modeless state.

It looks that there is some regression issues with tracking Parent window value when Modal windows are created.

There should be Mantis bug related to this.

Just tested... Such behavior (at least, MsgBox and CommonDialog) have 2.5.5.998, 3.0.6.1190 and 3.1.0.1218. So, I don't think it is a regression.

I have seen this happening for long time, the problem is it's hard to reproduce consistently. It also seems that MediaMonkey starts script dialogs as above anything and will later reset them to on top of MediaMonkey.

This seems to happen when the script is loading and takes a while (and a lot of resources). I will open another application window and the script window will appear on top, then at some point it disappears (still available when returning to MediaMonkey as active window). I've also seen this with Auto-Tag from Web.

Over time you will see users report this on the forum, but the issue seems to be the ability to reproduce it consistently across MediaMonkey installations.

Try to reproduce this way:
- If you didn't yet, download and install the last version of Last.fm scrobbler plugin here.
- Start MM
- Open a couple of folders (I used Documents and Recycle bin)
- Three is the perfect number...open also you browser (I used Firefox, just because I hate IE and Chrome is not that know yet, maybe)
Now, in MM, go to Options, General plugins. Select 'Last.fm scrobbler' and click Configure. A message will appear. Click NO (yeah, it makes no sense...just click it). Go get the option panel...somewhere.
Hope it works for who wants to reproduce it.

I don't know about built-in dialog boxes, but MsgBox and CommonDialog from scripts are always modeless For example:
- install the Magic Nodes script;
- go to Edit / Magic Nodes Export/Import;
- click on the File;
- click on the "..." button on the right side;
- when the new "Select a file..." dialog box appears, click on the previous dialog box (Magic Nodes Export/Import) -> you could easily cover the "Select..." dialog box with the "Export/Import" dialog box.

However, this is not only problem. More serious problem is a fact that you could click again on the "..." button and you would get another "Select a file..." dialog box, as many times as you click on it. Well, I could resolve this behavior within the script, but modeless state remains unresolved.

Ok, it seems somebody fixed this, but I still can see a couple of errors.
- This subpanel (Options\Input plugin\Monkey's audio player v3.99\Configure) is on ALWAYS on top, also when I MM has not the focus and I'm i.e. on my browser window. Other subpanels lose their priority when I swap to another window, and are still on top when MM gets th focus back. Could you make sure that all the panels and subpanels work this way for the release candidate?
- The last.fm scrobbler plugin still has the problem I decribed two posts above. But I'm posting it in the right topic, to be sure.

It is still not fixed (1235). CommonDialog and MsgBox from scripts still could be hidden behind other windows, although there should be modal windows. Is this usual Windows behavior manged by System?

ZvezdanD wrote:Is this usual Windows behavior manged by System?

Probably. I noticed that some windows in WinXP fall in background when they should be in foreground.

Fraxav wrote:

ZvezdanD wrote:Is this usual Windows behavior manged by System?

Probably. I noticed that some windows in WinXP fall in background when they should be in foreground.

No, you are wrong. My question was rhetorical and this is not usual Windows behavior at all. There is absolutely none Windows application which have MsgBox and CommonDialog dialog boxes that are not modal, i.e. that are modeless. If you don't know what I am talking about, the modal dialog is such window where you need to click on OK or Close or something else to return to main window and modeless dialog is such that you could use other options from the main window without closing that dialog. Also, if you need explanation, the CommonDialog is used for Open File and Save File in other applications. That dialog is always on the top of its parent application and you cannot use anything in that application until you choose Open or Cancel. Same state is for MsgBox - this dialog box is for displaying some important information, sometimes it is critical with errors and there is abolutely none regular Windows application where this dialog is modeless. Such message boxes needs user atention and an application should not continue with the execution until you don't decide what should be done.

We could discus here if their Options dialog box or Burn dialog or Convert or whatever else dialog should be modal or not, but MsgBox and CommonDialog should not be modeless at all. Yes, there are applications which have modeless dialog boxes which could go behind its main window. However, with many applications even modeless windows are on the top of its main window. Just take a look at Preferences from Winamp and many other Windows applications with modeless dialog boxes which I mentioned here: http://www.mediamonkey.com/forum/viewto ... 30#p199830. As I said in the that thread, MM developers generally have a problem with z-order of windows, i.e. with their foreground/active state.

Too bad.

1247 - still not fixed.

> For example, in the 'options' window you usually open new windows or dialogs
> to configure some plugins, etc... It's extremely easy that this sub-windows
> (if this name exists) or dialogs 'disappear' if you click, let's say, somewhere out of the dialog itself

FWIW, 1244 does not show this here. E.g. clicking outside Device Profile dialog causes beep, not disappear.