Use #WS_CLIPCHILDREN by default for container gadgets

[Mistrel]

Please use the #WS_CLIPCHILDREN window style by default for container gadgets on the Windows platform.

Excludes the area occupied by child windows when drawing occurs within the parent window. This style is used when creating the parent window.

It helps reduce gadget flickering and is perfectly suited for this gadget.

[freak]

It creates redraw problems with several other PB Gadgets, thats why it was removed.

[Mistrel]

Would you provide an example? (In the informative sense)

[srod]

Try throwing a panel gadget inside such a container; in the past the #WM_CLIPCHILDREN style has played merry buggery with this!

[Mistrel]

Setting the window style #WS_EX_COMPOSITED on a panel gadget fixes any redraw flickering associated with this issue. :roll:

http://www.purebasic.fr/english/viewtop ... 443#268443

Any other gadgets?

[eesau]

Isn't #WS_EX_COMPOSITED Windows XP only?

[Mistrel]

Isn't #WS_EX_COMPOSITED Windows XP only?

This is true!

[Fred]

Here is our comment:

Code: Select all

  /* Note: don't use  'WS_CLIPCHILDREN' as it will break with panel inside or listicon (redraw problem)
   */

[srod]

Setting the window style #WS_EX_COMPOSITED on a panel gadget fixes any redraw flickering associated with this issue. :roll:

http://www.purebasic.fr/english/viewtop ... 443#268443

Any other gadgets?

Not sure the eye roll is warranted here; you asked for an example of a gadget which has problems when the #WS_CLIPCHILDREN style is applied etc. and I gave you one. You said nothing about using double-buffering which is xp only (as has been stated) and will slow things down anyhow.

The fact is that when #WS_CLIPCHILDREN was added by default to a container, it caused a lot of people quite a few redrawing problems (particularly with xp themes enabled) and it was thus removed to be used at an individual's discretion.

[Sparkie]

Not sure the eye roll is warranted here

Mistrel has given many eye rolls in the past, most of which, IMO, have been unwarranted. My guess is Mistrel has a different take on :roll: than we do.

@Mistrel: What does :roll: mean to you

[Mistrel]

I have tested with XP styles enabled and disabled. There is slightly less flickering with #WS_CLIPCHILDREN.

There is still flickering either way which needs to be handled (#WS_CLIPCHILDREN or not). The #WS_EX_COMPOSITED example and the link was provided to show this and demonstrate how to make both a panel and a list gadget draw properly inside of a splitter. This solution also demonstrates how to benefit from the #WS_CLIPCHILDREN style.

The :roll: was merely a challenge "You can do better than that, srod!" and I provided an example to back it up. I still believe that this style helps more than hurts and it can always be disabled. But I still have yet to see a solid example that proves it hurts.

Would you provide an example? (In the informative sense)

I still have yet to see an example to demonstrate how #WS_CLIPCHILDREN creates more flickering. freak said there is a problem with some gadgets (which ones?), srod says panel gadgets (it does not appear worse here), fred says panels and lists (also not worse here), and Sparkie has publicly expressed his distaste of my use of :roll:.

What I'm asking is for an example or a link that demonstrates more flickering with this style using PB gadgets so that I'll know what to watch out for.

Code: Select all

OpenWindow(0,0,0,322,240,"ContainerGadget",#PB_Window_SystemMenu|#PB_Window_ScreenCentered|#PB_Window_SizeGadget)
ContainerGadget(0,8,32,306,133,#PB_Container_Raised)

;/ Panel
PanelGadget(1,0,0,306,200)
AddGadgetItem(1,-1,"Sub-Panel 1")
AddGadgetItem(1,-1,"Sub-Panel 2")
AddGadgetItem(1,-1,"Sub-Panel 3")
CloseGadgetList()

;/ List Icon
ListIconGadget(2,0,0,306,200,"",120)
For i=0 To 100
	AddGadgetItem(2,-1,"HelloHello"+#LF$+"HelloHelloHelloHello"+#LF$+"Hello")
Next
CloseGadgetList()
HideGadget(2,1)

;/ Toggle
ButtonGadget(3,8,8,100,22,"Show Toggle")
ButtonGadget(4,116,8,100,22,"Disable Style")

WindowStyle=GetWindowLongPtr_(GadgetID(0),#GWL_STYLE)
SetWindowLongPtr_(GadgetID(0),#GWL_STYLE,WindowStyle|#WS_CLIPCHILDREN)

Repeat
	Event=WaitWindowEvent()
	Select Event
		Case #PB_Event_SizeWindow
			ResizeGadget(0,8,32,WindowWidth(0)-16,WindowHeight(0)-40)
			
			GetClientRect_(GadgetID(0),@Rect.RECT)
			ResizeGadget(1,0,0,Rect\right,Rect\bottom)
			ResizeGadget(2,0,0,Rect\right,Rect\bottom)
		Case #PB_Event_Gadget
			If EventGadget()=3
				If Not ShowToggle
					HideGadget(1,1)
					HideGadget(2,0)
					ShowToggle=1
				Else
					HideGadget(1,0)
					HideGadget(2,1)
					ShowToggle=0
				EndIf
			EndIf
			If EventGadget()=4
				If Not StyleToggle
					WindowStyle=GetWindowLongPtr_(GadgetID(0),#GWL_STYLE)
					SetWindowLongPtr_(GadgetID(0),#GWL_STYLE,WindowStyle&(~#WS_CLIPCHILDREN))
					SetGadgetText(4,"Enable Style")
					StyleToggle=1
				Else
					WindowStyle=GetWindowLongPtr_(GadgetID(0),#GWL_STYLE)
					SetWindowLongPtr_(GadgetID(0),#GWL_STYLE,WindowStyle|#WS_CLIPCHILDREN)
					SetGadgetText(4,"Disable Style")
					StyleToggle=0
				EndIf
			EndIf
	EndSelect
Until Event=#PB_Event_CloseWindow

[Sparkie]

It's not that #WS_CLIPCHILDREN creates more flickering, it's that it caused redraw problems. I can't find the exact post as I think it was in the Bug Reports section and has since been zapped.

Take our word for it or don't....if #WS_CLIPCHILDREN works in your app then by all means use it.

[srod]

Aye, when using this style I have usually had to take extra steps as well - usually to accommodate the problems caused by using this style in the first place.

Mistrel, I don't mind a challenge - but it does need to be clear that's what it is! The fact is that I no longer use PB's panel gadgets anyhow; I will be rolling my own from now on. But one thing I do use quite a lot, and that is #WS_CLIPCHILDREN!

[Edwin Knoppert]

In my other language i create virtually all controls with the styles: WS_CLIPCHILDREN and WS_CLIPSIBLINGS

I have experiance with ownerdrawn controls and for example the listbox class can be difficult (area below the last item for example).

Imo you blame one for using valid styles and i suspect the 'original' controls where not properly created and tested.