1252 EDIT: Menu labels can go white [6856]

[chrisjj]

All or part of the normally black Now Playing menu bar label text can go white when the docked Now Playing window is resized:

1 See black (expected)

2 Slowly raise top edge - see partial white

3 Rapidly lower top edge - see whole white


Also presumably the same bug:

4 On window menu bar View right-click - see black (expected)

5 Click title bar - see partial white


Note that in

the main app title bar has changed colour indicating loss of focus. This is very non-standard behaviour for Windows apps and I suggest it may be related to a repaint failure that is causing this issue.

Likely related: http://www.mediamonkey.com/forum/viewto ... te#p204712


EDIT(TC) Tracked at http://www.ventismedia.com/mantis/view.php?id=6856

[rusty]

Can anyone else consistently reproduce this? (I can't)

-Rusty

[ZvezdanD]

the main app title bar has changed colour indicating loss of focus. This is very non-standard behaviour for Windows apps

I reported this to Jiri some times ago.

One more issue related to dropdown listboxes and pop-up menus which I
reported here:
http://www.mediamonkey.com/forum/viewto ... 15#p186415. Why the
click on the dropdown arrow leads to loosing active state of the form in the
skinned version? Just take a look on the color of the window's titlebar text
before the click on the dropdown arrow and after that - it is changing, but
it should not. None Windows program has such thing, neither non-skinned MM.
It seems that this is not happening with built-in dialog boxes and your
dropdown lists, but only with ones from scripts. Same behavior had skinned
MM2, even with some built-in dropdown lists (those from the Options dialog).

In MM3 such behavior only have some dropdown lists from the Device Profile
dialog box / Device Configuration tab - if you choose Generic Portable/Audio
Device, on the mentioned tab you have such Drive Letter dropdown list, and
if you choose iRiver ... Series you have such dropdown list next to the
Store Device database... However, as I said, this happens with all scripts
and their dropdown lists.

Same things happen when you display any pop-up menu by right-click, for
example in the tracklist or tree panel. Well, this is not a big deal, but it
is not standard Windows behavior.

Here is a response:

re. losing active state - thanks, will look into it, although probably not
with very high priority, as it might be a non-trivial change in the skinning
engine we use. We'll see...

[chrisjj]

I am baffled by the extent of the non-standardness if the MM UI, and this non-standardness ISTM is the cause of many of the UI bugs that I find in MM but not other apps. I can see why custom controls were used in some places, but it seems even the menu bar is non-standard. I could see no functionailty need for this until:

> it might be a non-trivial change in the skinning engine we use.

Is that the reason, and the only reason, for MM's reinvention of the menu bar wheel?

[rusty]

Like any app, MM uses some custom controls, but the skinning engine is the bit that contributes to some of the strangeness you observe. We held off on updating it for 3.1, but hope to do so for the next release.

-Rusty

[rovingcowboy]

i can't reproduce this in mm 3.0.3 but i did say elsewhere in another post about the same thing.
i have seen this before in windows explorer and IE or any app that used the explorer shell.

but i know it was corrected in the Xp SP 3 update i have not seen it since.

so rusty are you and petrcbr sure it is in the skin engine or is it just that chrisjj still can't update to sp3 because i think of some hardware issues he said he had with his system.

[chrisjj]

> the skinning engine is the bit that contributes to some of the strangeness you observe.

Even though I am using the non-skinned .exe? I was hoping my choice there had eliminated skinning artifacts interfering with testing.

[rovingcowboy]

> the skinning engine is the bit that contributes to some of the strangeness you observe.

Even though I am using the non-skinned .exe? I was hoping my choice there had eliminated skinning artifacts interfering with testing.

but chrisjj you forget. its not really unskinned. it has the skin in the exe and is set by the devleopers so there is a skin in the unskinned version its just a unskinned, skin, version. so some things from the skin engine might mess with the un skinned version skin. but us skinners can not change anything on the unskinned versions skin.

[chrisjj]

> but chrisjj you forget. its not really unskinned.

I never knew Thanks for that bad news RC

> its just a unskinned, skin, version. so some things from the skin engine might
> mess with the un skinned version skin.

Meaning these little UI problems such as label cropping, missing buttons and focus loss can crop up independently on every different skin??

[PetrCBR]

Non-skinned version is really non-skinned (not a skinned with windows theme). Skinning engine isn't implemented in this exe (so it uses default windows controls).

[rovingcowboy]

Non-skinned version is really non-skinned (not a skinned with windows theme). Skinning engine isn't implemented in this exe (so it uses default windows controls).

oh sorry i had been thinking it was the windows theme skin thanks for correcting me.
we ain't too old to learn something new after all i guess.

[chrisjj]

> Non-skinned version is really non-skinned (not a skinned with windows theme).
> Skinning engine isn't implemented in this exe

Good news - thanks.

> (so it uses default windows controls).

I think the Tree is not a default I.e. standard windows control.

[chrisjj]

How hard can this be to fix, guys??? Two years later (on 1306), still present:



Win XP SP2.

[chrisjj]

How hard can this be to fix, guys??? Two years later (on 1306), still present

Three years later, still present - and spread to toolbar items:



This on Windows 7 Pro 64 bit.

[chrisjj]

Five years on, still present. MM 1708:

XP:


Win 7:


The fact I find it on every machine makes surprising the reports here that it cannot be reproduced.