[Mono-winforms-list] Re: Mono-winforms-list digest, Vol 1 #37 - 12 msgs

[Vlad Kaluzhny]

Hi.
I  am pleased to introduce myself to all of you.
I am Vladimir Kaluzhny from Openlink Software Inc,
who is assigned by my bosses for full-time on Mono project
contribution, particularly on SWF.
I'd like to address your attention on very important thing -
I WILL TEST THE MONO SFW UNDER  WINE ONLY.
My additional task is to make Mono working under Wine.
Therefore, I gonna  warn you -  when you will note, that some
part of SWF is  declared by me as non-working, that means it is not
working under Wine. Agree?
Thus, all the lines in my recent diff being commented and marked as
non-working, do not work under Wine in fact, on my Linux box.
Therefore there is nothing strange, when you see the same code is
working with you, since, I believe, you test them on Windws.
Is this correct? Does someone else test the Mono under Wine?

Because the Ximian company does position Mono project on Linux
and MS Windows all code must be working on both environments-
on  MS Windows and on Wine under Linux. Therefore I am
truly asking to you - never cast doubt on my statements -
if I said it is not working, that means it is not working,
and particularly under Wine. Another question - why?

I want to work side by side with all of you and gonna trust to each other.
When some one have some doubts, the best way is to RTFM first.
I beg your pardon if my words seemed as abrupt to some one.


> From: mono-winforms-list-admin@lists.ximian.com
> [mailto:mono-winforms-list-admin@lists.ximian.com]
On Behalf Of Alexandre Pigolkine
> For example:
>
> --- Control.cs 20 Mar 2003 23:05:15 -0000 1.30
> +++ Control.cs 21 Mar 2003 10:43:47 -0000
>        SubclassWindow();
> -
> -      CreatorThreadId_ = Win32.GetCurrentThreadId();
> -
> +      /* vkaluzhny@openlinksw.co.uk = FIXME!!!!
> +      CreatorThreadId_ = Win32.GetCurrentThreadId(); */
>        OnHandleCreated (new EventArgs());

Alexandre! the GetCurrentThreadId() is absent in Wine!
this is the reason! Who will fix it - I dunno.

>       }
>
> The GetCurrentThreadId is used for ISynchronizeInvoke implementation :
> Samples\QuickStart\howto\samples\winforms\threadmarshal\.
>
> And why code in Button.cs is not working :
> Samples\QuickStart\winforms\samples\controlreference\buttonctl\.

Alexandre! it was not working under Wine.  now all is ok.

> It's also not clear why Window class registration code moved to Form.cs.
Is
> it needed to
> register class for every Form created ?

Alexandre!  See below, please

Next is the most important  - the class registration  functionality.

> Message: 3
> Date: Fri, 21 Mar 2003 04:57:14 -0800 (PST)
> From: Aleksey Ryabchuk <ryabchuk@yahoo.com>
> Subject: Re: [Mono-winforms-list] Introduction, patching, canonization,
roadmap.
> To: mono-winforms-list@lists.ximian.com
>
> Regarding the patch, I find it quite controversial.
> The movement of class registration from
> ScrollableControl to Form will break working of some
> other controls at the moment - Panel in particular. I
> also don't think that Control.Name property actually
> represents the name of the window class.

I would suggest to read  the MSDN first, but in order to save our time
I will explain all things here.
So - what is the window class and what is it for?
window class is the group of windows with the same properties.
the window class  registration put the specified class into list of objects,
which will wait for events, THEREFORE - Windows OS will  dispatch
the events onto that Windows objects, which are registered.
When Class is registering it is queued and this becomes to receive events.

Only controls do not need to be registered, since they are already
registered
by Operating Systems, so called pre-registered classes. they are:
BUTTON, LISTBOX, MDICLIENT, SCROLLBAR, STATIC, EDIT.

So you do not  need  to register these control wondows, before to create
them.
this is one of reasons,  why  registration must be removed from NativeWindow
class. since the Control class is parent class for controls (and Windows
too, which
I preffer to name Widgets) and  therefore the CreateHandle with class
registration
functionality would be called for  controls too. This is not needed.
Meantime all windows except Controls and MdiClients have to be  registered
first.

Among those windows are and  Form,  and Panel, and any Canvas, and MID Child
and so on.
This, class registration fucntionality must be specified for each type  of
windows.

Next - where to register the Windows before to create them.
There are three possible ways:

First one is implemeted in WxWindows library.
At application initaliziation  time the required classes will be registered.
wxWindows has the following classes of windows only :
CanvasClass, CanvasClassNR, MDIFrameClass,
MDIFrameClassNameNoRedraw, MDIChildFrameClass
MDIChildFrameClassNameNoRedraw
Then any   window will by created under any of above registered
classes depending on which  target is this window is creating on.

Disadvantage of this method is that only few classes are exist.
This make difficult to implement some features.

Second one is implemented in MFC. When new Window gonna be created,
it is checked, if the required class is registered. the number of classes
is  broad enough, but in any way it is limited.
When the new window is creating, it is checking if the desired class
(from the set of allowed) is registered. if so, the tue is returning.
if no, the class  is registering and the result (true or false) is
returning.

Third way is mine.  I guess this is the best for SWF.
we will  create special protected static member of Control class -
static  protected Hashtable classesList.
The key is the class name, the value is flag - is registered or no.
the class registration functionality  would be implemented
into "protected override void CreateHandle()" method as it written
by me in Form class,  but into all other SWF window classes, creation
handle of which is require to have registered class.
I told you  before - these SWF classes are - Form, Panel, MDI Child
and any other,  which require the registration.
the code as following:
if  ( !classesList[ClassName ) {
                WNDCLASS wndClass = new WNDCLASS();
                wndClass.style = CreateParams.ClassStyle;
                wndClass.lpfnWndProc = NativeWindow.GetWindowProc();
                wndClass.cbClsExtra = 0;
                wndClass.cbWndExtra = CreateParams.ExStyle;
                wndClass.hInstance = (IntPtr)0;
                wndClass.hIcon = (IntPtr)0;
                wndClass.hCursor = Win32.LoadCursor( (IntPtr)0,
LC_.IDC_ARROW);
                wndClass.hbrBackground =
(IntPtr)((int)GetSysColorIndex.COLOR_BTNFACE + 1);
                wndClass.lpszMenuName = "";
                wndClass.lpszClassName = ClassName;
                if (Win32.RegisterClass(ref wndClass) != 0) {
                       classesList[className] = true;
                } else
                    throw new Exception("Cannot register class");
 }
if  ( classesList[CreateParams.ClassName] )
                  base.CreateHandle ();
What is the benefit of this approach?
the benefit is that  following properties :

wndClass.style
wndClass.cbClsExtra
wndClass.hInstance
wndClass.hIcon
wndClass.hCursor
wndClass.hbrBackground

can have by user-specified values, what  gives much more flaxibility for
developer.

So,  we have three possible ways to register classes.
We can chose first one, second or third one.
Second is impemented in MS.NET Framework SWF.
Structly to say, we must implemenet particularly this
due the compatibility  (between MS.NET and Mono)  requirement.
What is the your opinion?
Especially  I am asking  to  the person,   who manages  Mono SWF.
Btw,  what is his/her  name and email?

The only correct note in mail-list re my diff, which I  am agree with, is
about the
assigning   the  Name member  of the  Control class  to the
wndClass.lpszClassName.
This point was mentioned by  Alexandre Pigolkine and by  Aleksey Ryabchuk.
I am agree - this is incorrect. But I did this for testing purposes only,
since the set of class names is not specified yet. When the set of class
names
will be specified and implemented, I will remove this, no doubts.
Thanks for  your feedback,  guys!

And the last question, I'd like to make clear.
Who manage the  possible duplications of code implementations.

I gonna write code for the following classes first of all:
1. Application
2. ApplicationContext
6. NativeWindow
3. Control
4. ContainerControl
5. ScrollableControl
6. Form

Gonna some one else to  attend with them?
Let us exclude the our efforts duplication!!!

Sincerely yours, Vlad Kaluzh.

PS. Who wants to contact me via ICQ, lemme know, I will send my OCQ ID then.