I wrote on the SourceForge discussion forum about the control painting changes that I started in Alpha 10, but I want to make sure it is noted here as well.
Basically, I'm starting over from scratch. I am still experimenting with different strategies for painting controls, so this will be an ongoing evolution over the next few builds. My goal is to rely as much as possible on Windows' optimizations in painting controls on the screen, and only override Windows' built in behaviors where necessary. Unfortunately, there are many situations where overriding the built in behavior is necessary; in those cases, my goal is to make the overrides consistent and common across controls to the extent possible, with minimal control-specific behavor.
If all controls always lived on the same color solid background like they did in the early days of Windows, this would be easy. In practice, though, it's an almost impossible task. Resizable dialogs introduce the well-known flashing effect when resizing. Tab controls introduce a different background color. Transparent controls require special handling to ensure that their background gets painted first, and completely, before the control is painted.
To make matters worse, different versions of Windows and different settings for Visual Styles can affect specific controls in different ways under different circumstances, so there is a need for special handling in certain cases.
I will have more to say on the subject once I get a better handle on how I will proceed. For now, just be warned that painting is not perfect in Alpha 10, and it will change over the next few builds, so there is no need to report painting bugs yet.
In Alpha 11, the control painting changes are starting to settle down. If you have forms that rely on some unusual behavior, please test things in Alpha 11 and report any problems. There are several potentially problematic situations:
1) Transparent controls. There are differences between Windows versions, using or not using visual styles, and the type of form. For example, transparent controls on a tab page for a tab strip using visual styles requires special handling that differs between Windows XP and Vista. In Alpha 11, I'm using a different approach to handling transparent controls in general. Instead of being truly transparent, "transparent" really means "paint the background the same color as the parent" -- at least generally (i.e. there are exceptions).
2) Overlapping controls. This has always been problematic. Transparent controls should always be painted after non-transparent controls, but there is no well defined way to put a control "on top of" another. If one control is transparent and one is not, then the transparent control should generally appear to be on top of the non-transparent control -- but how this actually looks in the end may depend on the types of controls. Tab order does not affect painting order -- at least not in any reliable way.
3) Flashing during resizing. This problem is a difficult one to solve. In some cases, double buffering can be used to solve it. In some cases, smarter repainting logic can minimize it. As a general rule, transparent controls are more likely to cause flashing. I will continue to work on this problem, but in many cases we're just stuck with it.
I'm testing during development with Windows 7, and I've tested briefly with Windows XP, but Alpha 11 really needs to be tested on a wider variety of Windows versions in case there are serious problems that require a change in strategy. Please test Alpha 11 in other Windows versions and report your findings by replying here.
Hi Owen
re: Alpha 11/Windows XP
I've noticed the following repainting issues:
1. transparent controls on a Tab Control
Check boxes - background colour, shows as white
Frames - caption background only, shows as white.
Rectangles - whole back ground is white, it also masks any other controls with in the rectangle.(presumably because of the reasons mentioned in your last post).
(Interestingly - Option buttons are repainting fine)
2. Labels (not on a tab control)
Overlapping labels lose their draw order (as specified in Studio).
Regards
Dan
XP SP3 AC2010 & 2007 Mech
I have some buttons that that are not enabled at initialisation. The buttons are enabled when the min required information is available to allow a logical continuation.
The butttons do not display untill I do a mouseover the button.
I'll try to define the problem more consisely and/or try to produce a minimalist project to demonstrate the issue .. won't be tonight or tomorrow though :)
ACADM2007 (Mech)
XP sp3 odcl 6.0.0.11
When NOT enabled the TextBox control displays a horixontal horizontal underline instead of being greyed out.
edit: DUH !
Quote from: Danner on November 03, 2009, 01:13:23 AM
1. transparent controls on a Tab Control
Check boxes - background colour, shows as white
Frames - caption background only, shows as white.
Rectangles - whole back ground is white, it also masks any other controls with in the rectangle.(presumably because of the reasons mentioned in your last post).
(Interestingly - Option buttons are repainting fine)
I tested with a tab control that uses visual styles, but I didn't think to test on one that doesn't. I've had to do a little bit of refactoring, but I think I've come up with a slightly improved system now that works reliably in all cases. Please test again in Alpha 12 and let me know the results.
Quote from: Danner on November 03, 2009, 01:13:23 AM
2. Labels (not on a tab control)
Overlapping labels lose their draw order (as specified in Studio).
In Windows, there is no real concept of "draw order". I assume you're referring to Z / Tab Order, which is confusingly similar. In fact, I think the nomenclature should be changed to just "Tab Order" to make it less confusing.
To reiterate what I posted before, the only way to reliably control the order in which overlapping controls are painted is to make one transparent and one not transparent. Windows (should) always paint transparent controls last.
Quote from: Kerry Brown on November 03, 2009, 05:10:13 PM
When NOT enabled the TextBox control displays a horixontal horizontal underline instead of being greyed out.
I can't reproduce with my current code, so it's either fixed or I'm not testing it right. Please test again in Alpha 12 when it's released and report any remaining (or new!) problems.
Quote from: owenwengerd on November 04, 2009, 06:47:04 PM
Quote from: Danner on November 03, 2009, 01:13:23 AM
2. Labels (not on a tab control)
Overlapping labels lose their draw order (as specified in Studio).
In Windows, there is no real concept of "draw order". I assume you're referring to Z / Tab Order, which is confusingly similar. In fact, I think the nomenclature should be changed to just "Tab Order" to make it less confusing.
To reiterate what I posted before, the only way to reliably control the order in which overlapping controls are painted is to make one transparent and one not transparent. Windows (should) always paint transparent controls last.
Yes, sorry I did indeed mean Z order. I see I can still invoke the function "Control_ZOrder"
after the actual Oninitiliaze event and it works. (Or should I be wary?)
Thanks.
Quote from: Danner on November 05, 2009, 07:39:34 AM
Yes, sorry I did indeed mean Z order. I see I can still invoke the function "Control_ZOrder" after the actual Oninitiliaze event and it works. (Or should I be wary?)
You should probably be wary, but I'd like to see an example of what you're referring to.
Quote from: owenwengerd on November 05, 2009, 09:35:47 AM
Quote from: Danner on November 05, 2009, 07:39:34 AM
Yes, sorry I did indeed mean Z order. I see I can still invoke the function "Control_ZOrder" after the actual Oninitiliaze event and it works. (Or should I be wary?)
You should probably be wary, but I'd like to see an example of what you're referring to.
Here you go - please see a video below:
RectangleDemo (http://www.screencast.com/t/hkNfIDhKz)
Behind each blockview there is a green rectangle set to invisible. Selecting a blockview or a blockname from the listbox - makes the rectangle visible and send it behind the blockview with the following subroutine:
(defun SET_RECTANGLE_VIS (NSel_Int / RectangleList)
(setq RectangleList (GET_RECTANGLE_CONTROL_LIST))
;set rectangle visible
(dcl_Control_SetVisible (nth NSel_Int RectangleList) T)
;put rectangle behind blockview
(dcl_Control_ZOrder (nth NSel_Int RectangleList) 1)
);endfun
The routine seems to be working fine now I've added "(dcl_Control_ZOrder....", but now I'm rather circumspect.
Hi, Danner, have a look here (http://www.opendcl.com/forum/index.php?topic=786.msg3880#msg3880). There you can see a highlighting rectangle. Maybe it would be better to use SetHighlight (http://www.opendcl.com/HelpFiles/index.php?page=Reference/Method/DwgPreview/SetHighlight.htm)-method.
Fred
Quote from: Fred Tomke on November 06, 2009, 03:41:51 AM
Hi, Danner, have a look here (http://www.opendcl.com/forum/index.php?topic=786.msg3880#msg3880). There you can see a highlighting rectangle. Maybe it would be better to use SetHighlight (http://www.opendcl.com/HelpFiles/index.php?page=Reference/Method/DwgPreview/SetHighlight.htm)-method.
Fred
Thanks Fred,
Interesting - I wasn't keen on the SetHighlight method, because I find the highlight rectangle difficult to see when the blockviews are numerous and rather small.
I see in your example that you have placed a "colour wash" on the highlighted preview which is very effective. Did you use SetBackgroundColor to do that - I didn't think that worked very well on BlockViews (see http://www.opendcl.com/forum/index.php?topic=703.15 (http://www.opendcl.com/forum/index.php?topic=703.15)? If it works fine - great, I've got a plan B! (I would still like to use my rectangles -all things being equal, so I don't have to change my code.)
Hi, I'm using DWGPreviews in that form because of the delay of loading a block in BlockView. So SetBackColor works very well for me.
Fred
For that purpose, your method might be fine. What happens in your example if you switch to a different window (that covers your dialog), then back? hat is you move the dialog partially off screen, then back on? If those cases work in all your supported operating systems, then I think you are safe.
Quote from: owenwengerd on November 06, 2009, 07:50:07 AM
For that purpose, your method might be fine. What happens in your example if you switch to a different window (that covers your dialog), then back? hat is you move the dialog partially off screen, then back on? If those cases work in all your supported operating systems, then I think you are safe.
Ah good. Works on xp will try Vista next week.
Quote from: owenwengerd on November 04, 2009, 06:43:44 PM
I tested with a tab control that uses visual styles, but I didn't think to test on one that doesn't. I've had to do a little bit of refactoring, but I think I've come up with a slightly improved system now that works reliably in all cases. Please test again in Alpha 12 and let me know the results.
Transparant contols on tabs in Alpha 12 are working properly now. Cheers.