Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Drawing issues with Windows 7
I've found that when using windows 7, more often than not our buttons wouldn't draw properly. They would basically be blank until the mouse was moved over them and then they would display as expected.
This has bugged me for a while because a client had a mass update of hardware and everyone moved from XP classic mode to windows 7.
Whilst the general appearance looks a lot better, in a lot of cases it has relied on the user knowing where buttons were so they could move their mouse over them to read the caption or see the icon.
If we had say 10 buttons on a form, maybe one or two would draw properly and the rest would require a mouse hover.
I've just found that it only occurs with the buttons whose style is set to 'XP' (which in our case was the majority of buttons).
We want the buttons to retain this style because we like the visual feedback it provides so changing the style is not an option.
So, I played a little more and found a resolution. The answer is in the sequence of setting the properties. If we set the style property before we set the caption/captionlist and/or icon/iconlist properties then we see the above behaviour.
Set the style last and the the buttons draw themselves every time.
So, if you are likely to use the 'XP' style for your buttons make sure you set the style after defining the other characteristics and everything should appear as expected.
Just throwing that out there in case anyone else had experienced similar issues.
This has bugged me for a while because a client had a mass update of hardware and everyone moved from XP classic mode to windows 7.
Whilst the general appearance looks a lot better, in a lot of cases it has relied on the user knowing where buttons were so they could move their mouse over them to read the caption or see the icon.
If we had say 10 buttons on a form, maybe one or two would draw properly and the rest would require a mouse hover.
I've just found that it only occurs with the buttons whose style is set to 'XP' (which in our case was the majority of buttons).
We want the buttons to retain this style because we like the visual feedback it provides so changing the style is not an option.
So, I played a little more and found a resolution. The answer is in the sequence of setting the properties. If we set the style property before we set the caption/captionlist and/or icon/iconlist properties then we see the above behaviour.
Set the style last and the the buttons draw themselves every time.
So, if you are likely to use the 'XP' style for your buttons make sure you set the style after defining the other characteristics and everything should appear as expected.
Just throwing that out there in case anyone else had experienced similar issues.
Comments
Your contribution to this issue is greatly appreciated. While I am happy to see that you found a resolution, I would really like to see the problem occur on my system as it does for yours. How predictable have the display problems been?
With most windows probably 70-80% of the buttons have this problem.
I use one function to initialise all buttons the same way. I just pass in the things that differ such as the caption and image.
The function does all the property setting.
Below are two shots of a window I'm just developing now. Both are shots when I first create the window. The only difference is I've changed the initialize function to set the style before the other properties for the first one and then the second one, the style gets set after the caption and icon properties.
As mentioned above it only seems to be a problem if the style is 'XP'
All these buttons are just defined one after the other.
Set the style after setting the icon and all of them appear as desired.
Setting the style after the other properties is not a resolution in itself.
The problem is the setting of the style before the caption/icon properties.
So if you set the style, then set the caption etc and then set the style again afterwards, you won't necessarily resolve the issue.
You need to remove the setting of the style that occurs first.
I am back on site today where I first noticed the problem for the client that I mentioned initially. I've made the same change here and received the same improved results.
Good to know and thanks for the update. I have yet to replicate your problem due to other pressing issues, but I intend to visit this just to confirm that this is a universal problem.