[Mono-bugs] [Bug 81135][Nor] New - XplatUIX11 WS_EX_TRANSPARENT not supported

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by contact at i-nz.net.

http://bugzilla.ximian.com/show_bug.cgi?id=81135

--- shadow/81135	2007-03-13 21:54:43.000000000 -0500
+++ shadow/81135.tmp.8389	2007-03-13 21:54:43.000000000 -0500
@@ -0,0 +1,85 @@
+Bug#: 81135
+Product: Mono: Class Libraries
+Version: 1.2
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: Windows.Forms
+AssignedTo: toshok at ximian.com                            
+ReportedBy: contact at i-nz.net               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: XplatUIX11 WS_EX_TRANSPARENT not supported
+
+What should happen when WS_EX_TRANSPARENT is set is
+that transparency for the control is simulated. When the transparent
+control is going to receive WM_PAINT, first its container and other
+controls will be send a WM_PAINT before the transparent control get
+its. This behaviour is in Windows itself, so it works with the Win32
+xplatui backend and is not Control.cs specific.
+
+This is a broken try to achieve that and it is here only to poke Toshok's
+brain how wrong it is and to help him out when implementing it :-).
+
+		private void SimulateTransparency (Hwnd hwnd)
+		{
+			if (hwnd.Transparent) {
+				hwnd.Queue.Paint.Remove(hwnd);
+				Control parent = Control.FromHandle (GetParent (hwnd.Handle));
+				
+				if (parent != null) {
+					Control.ControlCollection parentControls = parent.Controls;
+					int transpIndex = parentControls.IndexOf (Control.FromHandle
+(hwnd.Handle));
+					Invalidate (parent.Handle, parent.ClientRectangle, true);
+					UpdateWindow (parent.Handle);
+					for (int i = 0; i < parentControls.Count; i++) {
+						if (i != transpIndex) {
+							Invalidate (parentControls[i].Handle,
+parentControls[i].ClientRectangle, true);
+							UpdateWindow (parentControls[i].Handle);
+						}
+					}
+				}
+			}
+		}
+
+
+(00:38:50) toshok:you need to somehow flag a paint event as being
+synthetic, for use in painting the background on a transparent control
+(00:39:00) toshok: so when the control does PaintEventStart they get a
+Graphics object that draws to the transparent control, not to their control
+(00:39:10) toshok: synthetic meaning it's generated by the XplatUIX11.cs
+code, not from the X server
+(00:39:38) toshok: so yeah, this is probably better not handled in AddExpose
+(00:40:26) toshok: or else it'll needlessly complicate the paint queue even
+further, which I don't want
+(00:42:44) i-nZ: the change for the paintevent args to be the transparent
+ones can be done in PaintEventStart probably
+(00:42:51) toshok: actually this will still needlessly complicate it
+(00:43:09) toshok: it's not as simple as replacing the handle
+(00:43:19) toshok: because PaintEventStart clears the invalid area
+(00:44:37) i-nZ: uh nasty
+(00:45:26) i-nZ: but what's the problem with clearing the transparent
+control area?
+(00:45:32) i-nZ: since then it is going to be redrawn
+(00:45:56) toshok: it's not clearing the transparent control area
+(00:46:02) toshok: take the following case:
+(00:46:11) toshok: Control1 is not transparent
+(00:46:15) toshok: Control2 is transparent
+(00:46:19) toshok: both are children of the same parent
+(00:46:34) toshok: we get an expose event on Control1, in an area that is
+*not* overlapped by Control2
+(00:46:40) toshok: that gets added to the queue
+(00:46:47) toshok: we then get an expose event for Control2
+(00:47:05) toshok: Control2, being transparent, forces WM_PAINT messages to
+be sent to the parent as well as Control1
+(00:47:20) toshok: Control1 calls PaintEventStart, which clears its idea of
+the invalid area after generating the paint event
+(00:47:33) toshok: that clearing of the invalid area clears both areas
+(00:47:41) toshok: not just the one synthetically added by Control2