|
Hi,
I have a form with three horizontal scrollbars. The form has a colour scheme supplied by my client which specifies a background colour of AliceBlue for controls. The other controls all display this as the background color but when I set the BackColor property of the scrollbar it seems to be totally ignored and I end up with the usual boring grey background.
Anyone know why this is ignored? Is there a way to force the scrollbars to have a custom background colour?
Thanks in advance for any assistance....
Mike.
|
| MigrationUser 1 Sunday, May 11, 2003 3:24 AM |
you don't have a manifest setup for using XP styles with your application do you? |
| MigrationUser 1 Sunday, May 11, 2003 10:27 AM |
No, just using the default windows styles.
|
| MigrationUser 1 Sunday, May 11, 2003 6:21 PM |
Hey folks... someone out there must know why setting the background colour of certain controls in .Net is ignored!! I'm not doing *anything* fancy whatsoever with my controls or form etc - but it doesn't matter where I set the background colour, it just gets ignored!
I've tried looking into over-riding the method that sets that background but I have no idea how to find out what method would do this... anyone know?
This is driving me crazy - my app looks half finished because these stupid scrollbars won't keep their backgound colour... :-(
Jacob (or any gurus!) - are you out there... any ideas on this?
TIA...
Mike |
| MigrationUser 1 Friday, June 06, 2003 1:26 AM |
Are these scrollbars off the toolbox? Then it should be doable... The parent container should receive a WM_CTLCOLORSCROLLBAR message. So, you can handle it and provide the handle to a brush as the result... Unfortunately, the Brush classes don't expose a handle, so you need to use the API to create one as well as remember to destroy it.
Here are the necessary declarations:
Public Const WM_CTLCOLORSCROLLBAR As Integer = &H137 Declare Function CreateSolidBrush Lib "gdi32" Alias "CreateSolidBrush" (ByVal crColor As Integer) As IntPtr Declare Function DeleteObject Lib "gdi32" Alias "DeleteObject" (ByVal hObject As IntPtr) As Integer Private m_hBrush As IntPtr = IntPtr.Zero
In your constructor, create the brush that you will be using:
Dim colorValue As Integer = CInt("&H00" & Hex(Color.Gold.B) & Hex(Color.Gold.G) & Hex(Color.Gold.R)) m_hBrush = CreateSolidBrush(colorValue)
I was testing with Gold, as you can see above... The "colorValue" variable is a kludge, but I couldn't get it to work any other way.
Then, you need to override WndProc in your form:
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message) If m.Msg = WM_CTLCOLORSCROLLBAR Then m.Result = m_hBrush Else MyBase.WndProc(m) End If End Sub
Regardless, then, in the dispose method of your form:
If Not IntPtr.Equals(m_hBrush, IntPtr.Zero) Then DeleteObject(m_hBrush) End If
Let me know if you have questions... That should get you well on your way... |
| MigrationUser 1 Friday, June 06, 2003 12:01 PM |
Jacob,
Thanks very much for that detailed answer - you're da man!
I am using the standard HScrollBar control from the toolbox so I'll give it a go and let you know how I get on... haven't done anything with WndProc etc so far so no doubt it will be another learning experience!
Before I do go down that path though I just want to ask if you know why the BackColor & ForeColor properties on controls such as these is ignored? Is it a bug? Surely if these controls inherit from System.Windows.Forms.Control they should properly implement the BackColor/ForeColor properties but they clearly don't. I used Lutz Roeder's .Net Reflector (which I assume you use - fantastic bit of software!) to look at the ScrollBar class - and, as I expected, the code for the BackColor and ForeColor is the standard code inherited from the Control class. It even has events such as BackColorChanged which, when I debug them, tell me that the color I assigned to BackColor is correct - eg: AliceBlue - but the control simply does not update the color... what are your feelings on this? It looks a bug to me but maybe I'm missing something here!
Thanks again for the code... will give it a go now.
Mike.
|
| MigrationUser 1 Saturday, June 07, 2003 1:32 AM |
Jacob,
Just tried your solution and it worked perfectly first time... and here I was getting nervous about using WndProc!
Seems crazy to have to do this sort of thing just to set a background colour but at least now I kow how to do it. Now I'm thinking of creating a custom scrollbar control where the background colour can be set at runtime using this method... would be a good learning exercise methinks.
Thanks again - this is the second time in about a week you've solved a big problem for me!
Mike.
|
| MigrationUser 1 Saturday, June 07, 2003 2:40 AM |
I don't know if I would call it a bug, per se... It's more of an "implementation detail." I certainly can't speak for the Windows Forms team (until they offer me a job, that is ;) ) but there are a few places throughout the toolbox where things don't behave as you would expect. It was probably a situation where they just wrapped the Win32 scrollbar and didn't accomodate for properties that they weren't used to handling (like backColor). I don't know if it was a function of time or they didn't think people needed them, but I imagine that the next version can only be better with respect to overall property support. |
| MigrationUser 1 Monday, June 09, 2003 10:07 AM |
Awesome! Glad it worked for you... I think that would be an excellent learning exercise to wrap it into a standalone control.
WndProc definitely comes in handy. I find that I use it far too frequently... |
| MigrationUser 1 Monday, June 09, 2003 10:09 AM |
Yeah, I guess that one fish that slipped through the net - although you'd think the unit testing for controls would specify for these sort of things to be tested. I have to admit I haven't found that many bugs in .Net (not that I've tried every class, method, property etc!) but in general most controls and methods etc do what they say on the can so can't really complain. Am surprised that they didn't fix things like this (or the mutlitude of problems with the tab control) for v1.1 but I guess everything will be done for v2.0... whenever that may be!
I've only just noticed that you're *not* a moderator or member of the forum team - I thought you were one of the main moderators since I seem to see your name most often on posts helping people out... they *should* give you a job straight away!!! ;-) (Where the heck do you get the time to answer so many Q's?)
And while they're at it, a job for me too - my role would be to ask simple (stupid?) questions so it makes you guys look even better!
Mike.
|
| MigrationUser 1 Monday, June 09, 2003 6:56 PM |