[Mono-winforms-list] [RFC] Multiple NativeWindows per Handle Patch for bug #374660

Ivan N. Zlatev contact at i-nz.net
Mon May 5 16:34:49 EDT 2008

Hey Team,

To fix bug #374660
(https://bugzilla.novell.com/show_bug.cgi?id=374660) I had to
introduce support in NativeWindow for dealing with multiple
NativeWindows per Handle, where one (the first one) is organic (the
ControlNativeWindow) and the rest are synthetic. Messages pass through
both. This is allowed in MS's implementation and is what the test code
in the bug uses to loose couple the drawing code from the behavior
code. Ugly I know, but I guess seems natural to people coming from
hardcore Win32 coding background or something.

Anyway the attached patch, which I am asking you to check out just in case:

   * All tests pass. woo! In theory no regressions.
   * Handles single handle vs multiple handles in the following way,
where window_collection is a Hashtable with key-value pair, where the
key is the handle and the value is either a single NativeWindow or an
ArrayList of handles

				object current = window_collection[handle];
				if (current != null) {
					NativeWindow currentWindow = current as NativeWindow;
					if (currentWindow != null) {
						// only one handle - do stuff
					} else { // list of windows
						ArrayList windows = (ArrayList) window_collection[handle];
						// multiple handles (first one is organic always) - do stuff

   * Most notably doesn't increase our current memory consumption and
should not have any performance impact.

   * Probably decreases the current memory consumption a bit. It came
to my attention that NativeWindow.FromHandle instantiates a new
NativeWindow instead of returning one from the internal table.

   * NativeWindow.window_handle: internal -> private - we don't use
this anywhere and we shouldn't provide access to this to future code
as it breaks encapuslation and allows avoiding
AssignHandle/CreateHandle, InvalidateHandle. Evil.

   * NativeWindow.windows_collection: internal -> private - now that
multiple handles are allowed and the way those are handled is an
implementation detail, code shouldn't have access to the collection
directly. I have replaced the few direct references to the field with
a method to return the organic handle.

Does anyone have any objections or should I go ahead and commit?

Thanks in advance,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple-windows-per-handle.patch
Type: text/x-patch
Size: 11885 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-winforms-list/attachments/20080505/a56e3a5b/attachment.bin 

More information about the Mono-winforms-list mailing list