[Mono-winforms-list] Window class registration, Aleksey Ryabchuk's suggestions
Mon, 24 Mar 2003 17:58:50 +0600
----- Original Message -----
From: "Aleksey Ryabchuk" <firstname.lastname@example.org>
Sent: Monday, March 24, 2003 17:11
Subject: Re: [Mono-winforms-list] Final changes re Window
> Some remarks ...
> regarding this change:
> /* there was variable name duplication - we have it
> as member of parent class. email@example.com
> 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
> 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
Meantime, the used approach, I think, to register class is opitmazed
and nothing can be improved over there. I guess :-)
> 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
> --- Vlad Kaluzhny <firstname.lastname@example.org> 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