Screenshot supplied shows the issue I am having.
It seems the top half of these buttons will always retain the colour you have assigned to your basic buttons (green tone in my attached image), then fade into transparent. Naturally this looks awful if you want to set the button background to a colour that doesn't match well with your default buttons colour.
I have some custom gradient brushes which are proven to work, in my screenshot they are applied as proof with my options settings also visible to you. Whenever a gradient is aplied to the button backgrounds though they just seem to default to a flipped version of the default button colour scheme (green). Options menu in screenshot shows red gradient applied but overridden with default green button gradient.
Would any user or dev please let me know how to either:
* Allow my custom gradient brushes to completely override all gradients on the button. (Ideal and would look by far the best)
* Allow this shadow colour to be edited seperately and not linked to one of the colours assigned to default buttons in BluePrint.xaml.
(2nd Ideal, I would probably set the shadow to a neutral grey colour that went well with all colours. Although in practice I have tested this before by using grey for my normal button colours, I was never able to get the shadow to look right due to the fact it doesn't blend with the custom button background colour I have set in the options. Oddly if any alpha is applied it seems to show the colour of the panel background BEHIND the button. I had expected this to work similar to a layers sytem where this 'shadow' is layered on top of the button, thus any alpha applied would reveal the tint of the button background colour and blend in a pleasing way.
* Get rid of this persistent shadow.
(Last resort, would have to make do with flat shaded buttons. Hardly a disaster but the new gradient features do look nice )
I noted "BasicEntry.ButtonBackground" in BasicEntry.xaml does nothing. Excuse the garish green backgrounds, it's a skin for testing
More Info Discovered
I've now learnt that the persitent shadow of death is hardcoded to the colour of ButtonBackgroundStop1. If I assign any custom gradient brush to that button via the options menu the button background will overrirde my choice and create a gradient consisting of the ButtonBackgroundStop1 + ButtonBackgroundStop2 colours. These colours happened to be a flipped version of my button gradient setup hence my confusion believing it was defaulting to my button colours.
So what needs to be fixed is to stop that hardcoded fallback to the ButtonBackgroundStop colours and allow my custom gradient brush to take effect. As it is set up now you could alter both ButtonBackgroundStop1 & 2 to achieve your desired gradient, however this would only allow one gradient colour for all 3 button types [buy buttons] [sell buttons] [action buttons] since they are all coded to fall back to the same colour references.
Another Possible Bug Found
During my experiments I've found some inconsistent behaviour with the text colour on highlighted menu items.
Editing this tag:
<!-- Color for highlighted menu items across the application (menu titles and items within menus -->
<SolidColorBrush x:Key="FontMenuHighlightedBrush" Color="#FF000000" po:Freeze="true"/>
Produces the desired effect on some menus/items but not others. Here is what I am seeing:
- Right click basic entry window: Highlights Affected OK. (showing as black per my XAML edit)
- "New" menu in control center: Highlights NO effect.
- Tools menu in control center: All NO effect EXCEPT import and export options (weird huh).
- Workspaces menu in control center: Highlights OK.
- Connections menu: OK.
- Help menu: NO effect.
- Right click anywhere in the 'Logs' tab: First 2 menu items NO effect, last 5 items OK.
I don't know how all this is coded but this smells like someone forgot to add some kind of tag to certain menu items, so they are not referencing the same XAML tags for their colour info.
I've only listed 7 examples but every tab of the control center has these same anomalies on their right click menus, so someone has a lot of checking to do . There's probably many more examples throughout the application, unfortunately it looks like every menu is going to have to be checked for consistency.
Comment