View Issue Details

IDProjectCategoryView StatusLast Update
0000247OpenMPTUser Interfacepublic2012-05-06 19:12
Reporterharbinger Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
Status closedResolutionno change required 
Platformx86OSWindowsOS VersionXP
Product VersionOpenMPT 1.20.01.* (old testing) 
Summary0000247: Minimize/Restore boxes are not independent between songs, & Drawing glitch
Description

Not sure if this first part would be called a "bug" as much as simply anamolic.

Each song window INSIDE ModPlug's main window has three of its own buttons. A Resize button, a Restore button, and a close box. The ones we're concerned with are the Resize buttons and Restore buttons.
Default behavior is for ModPlug to open a song window at "Maximized", in which the child window occupies all the available ("client") space inside the main or "parent" window. As a side note, i've noticed that sometimes windows of tracks which were saved in previous versions opened in non-maximized, non-minimized child windows. In the Maximized state, the child windows buttons become "Minimize" and "Restore Down," which appear in their tooltips. Click on the Minimize button, which (in Windows XP's default theme at least) shows as a solid line, like an underscore, and the child window hides and the titlebar is reduced to a smaller size at the bottom left of the parent window. If you were to instead click on the "Restore Down" button, which looks like a pair of small open boxes, the child window shrinks to a default size (or the last dragged size) in the middle of the parent window (or wherever it was last dragged by the user).
In the "Minimized" state, the buttons change to "Restore Up" and "Maximize," and do what you might expect. In the child window's "Restored" state, which was the last default or custom dimensions of the window, you can either Minimize or Maximize the child window.
All this is fine, but one wonders WHY you would want to minimize a song window inside the parent window. It seems it's ideal under two scenarios: when you want to open multiple tabs for the same track ("MultiView"), or if you want to compare two different tracks, each in their own window.

Steps To Reproduce

However, this is where the anomaly appears.
Open two different modules. Make sure they're both in Maximum state.
Now click on the "Restore Down" of the current child window. You'll notice BOTH windows go to the default or custom size and location. You would think the top one would and the other window would stay maximized in the background. But it doesn't.
Now minimize both, so that they're side by side at the bottom. Click on the "Restore Up" button (the one with the underscore). It now MAXIMIZES. And if you select the other window by choosing that song from the Window menu, the other one has also maximized. If you click on the Minimize button, they BOTH become minimized at the bottom.

One would think that these processes would be independent, but this may be the nature of child windows. Plus from a practical point of view, there's not too many times when you need one window maximized at the other minimized in front of it.

Additional Information

However, i did notice a real bug. There is a drawing glitch in the gray background behind the tabs when resizing the windows either with the buttons or by clicking-and-dragging, in what they call a HOM effect. There seems to be a draw refresh command missing.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2012-05-06 19:12

administrator   ~0000711

It is part of the MDI idiom that all child windows have the same window state - It is not possible to have one of them windowed and another one maximised. Welcome to Windows.

Also I can't do anything against the drawing glitch; I have already said in the 1.20 announcement thread that graphical glitches only appear with the testing versions and not with the release versions. Get OpenMPT 1.20.01.00 and the glitch will be gone.

Issue History

Date Modified Username Field Change
2012-05-06 17:12 harbinger New Issue
2012-05-06 17:18 harbinger Severity feature => tweak
2012-05-06 19:12 Saga Musix Note Added: 0000711
2012-05-06 19:12 Saga Musix Status new => closed
2012-05-06 19:12 Saga Musix Assigned To => Saga Musix
2012-05-06 19:12 Saga Musix Resolution open => no change required
2012-05-06 19:12 Saga Musix Assigned To Saga Musix =>