[Mono-winforms-list] Window class registration, Aleksey Ryabchuk's suggestions

[Vlad Kaluzhny]

Hi.

----- Original Message -----
From: "Aleksey Ryabchuk" <ryabchuk@yahoo.com>
To: <mono-winforms-list@lists.ximian.com>
Sent: Monday, March 24, 2003 17:11
Subject: Re: [Mono-winforms-list] Final changes re Window
registrationprocedure


> Some remarks ...
>
> regarding this change:
>
> /* there was  variable name duplication - we have it
> as member of parent class. vkaluzhny@openlinksw.co.uk
> */
> createParams = new CreateParams ();
>
> I don't think that the base class, namely ButtonBase,
> should declare that field at all. It should override
> CreateParams property, create new instance of
> CreateParams class and set properties common to all
> ButtonBase-derived classes. Derived classes should
> call the base.CreateParams. Otherwise, I don't see any
> reason why ButtonBase overrides this property at all,
> if it does not do anything useful.


Aleksey,  Honesty to say, this field was not created  by me.
I just fixed the bug, because presence of two copies
(as class member and local variable) of the same
variable  caused the situation, when on one place  the value
is designating to one copy, and on other place is  using the value
of another copy. I guess i've got what I mean.
I think the same, that CreateParams varaible as the member of
ButtonBase class is not required here.

> Regarding GetCurrentThreadId, I'm really wondering how
> it can be absent in Wine, if a quick look at the
> Wine's sources shows that it is being used throughout
> the Wine's code. Though I'm not a Wine user and may be
> mistaken.
>
> Regarding your RegisterClass function... I believe
> that the Hashtable container is not appropriate here.
> May be it's better to use some set-like container.
> What sense does it make to put "this" pointer in
> hashtable ? I'm afraid that it will result in not
> GC-ing of some NativeWindow instances

Hashtable is a good place to hold the indexed data.
other code is more complicated.

You are correct, "this" is not a good flag.  I will use use another  flag
value.

Meantime, the used  approach,  I think, to register class is opitmazed
and nothing  can be improved over there. I guess :-)

>>Again, you
> say that we should use constants from
> win32functions.cs for window class names, but may be
> we have to do it for names like "BUTTON", "STATIC",
> etc. as well. Just for consistency purpose.

In fact you are correct, this is  convenient. I will implement this then

> wbr
> ary
>
> --- Vlad Kaluzhny <vkaluzhny@openlinksw.co.uk> wrote:
> > Hi.
> > After analizing of the guys wishes, I have modified
> > the Window Class
> > registration.
> > The only suggestion - use the class names, which are
> > described in Win32
> > class
> > (I put them in win32functions.cs file). Or add there
> > your class name, if you
> > need it.
> > This will avoid the class names duplications with
> > small and/or  capital
> > chars mixture.
> >
> > And Second,  be attentive when specify the
> > CreateParams.ClassStyle value.
> > It is simply duplication of class being registered,
> > when you have the same
> > style for
> > different classes. Another to say - when assign new
> > class name, take care,
> > that
> > it have the style, which  is not specified for
> > another  window class.
> >
> > Regards, Vlad
> >
>
> > ATTACHMENT part 2 application/octet-stream
> name=res2.diff
>