View>>winClassName vs. View>>wndClassName?

D5B2 appears has a new class method on View: #wndClassName.  D4 had
#winClassName but no #wndClassName ("win" vs. "wnd").  D5 has both methods.
Is this by design?  The methods have identical comments but different code.

I'm finding it necessary to override #wndClassName in my View subclass in
order to get it to register (via #registerClass).  In previous Dolphin
versions, I overrode #winClassName.

"Chris Hayes" <hayes@*zapthis*.creative-computing-inc.com> wrote in message
news:[hidden email]...
> D5B2 appears has a new class method on View: #wndClassName.  D4 had
> #winClassName but no #wndClassName ("win" vs. "wnd").  D5 has both
methods.
> Is this by design?  The methods have identical comments but different
code.
>
> I'm finding it necessary to override #wndClassName in my View subclass in
> order to get it to register (via #registerClass).  In previous Dolphin
> versions, I overrode #winClassName.
>
>

Yes, this is by design. The #wndClassName answers the name to be used when
registering a class, #winClassName answers the name (or atom) to be used
when creating an instance of the window.

Why are you finding it necessary to register your own window class though,
it isn't necessary to do that to implement "custom" views in Dolphin, since
in effect the whole Windows class mechanism is replaced by view classes in
Dolphin itself?

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
>
> "Chris Hayes" <hayes@*zapthis*.creative-computing-inc.com> wrote in
message
> news:[hidden email]...
> > D5B2 appears has a new class method on View: #wndClassName.  D4 had
> > #winClassName but no #wndClassName ("win" vs. "wnd").  D5 has both
> methods.
> > Is this by design?  The methods have identical comments but different
> code.
> >
> > I'm finding it necessary to override #wndClassName in my View subclass
in
> > order to get it to register (via #registerClass).  In previous Dolphin
> > versions, I overrode #winClassName.
> >
> >
>
> Yes, this is by design. The #wndClassName answers the name to be used when
> registering a class, #winClassName answers the name (or atom) to be used
> when creating an instance of the window.
>


OK (Perhaps this distinction could be made in the respective method
comments?)


> Why are you finding it necessary to register your own window class though,
> it isn't necessary to do that to implement "custom" views in Dolphin,
since
> in effect the whole Windows class mechanism is replaced by view classes in
> Dolphin itself?
>

I need an additonal bit set in the class style for OpenGL views (CS_OWNDC)
and overrode #winClassStyle.   My understanding is that the View subclass
must be registered in order for this style to take affect.

Thanks,

Chris

"Chris Hayes" <hayes@*zapthis*.creative-computing-inc.com> wrote in message
news:[hidden email]... when
> > registering a class, #winClassName answers the name (or atom) to be used
> > when creating an instance of the window.
> >
>
>
> OK (Perhaps this distinction could be made in the respective method
> comments?)

Of course.

> > Why are you finding it necessary to register your own window class
though,
> > it isn't necessary to do that to implement "custom" views in Dolphin,
> since
> > in effect the whole Windows class mechanism is replaced by view classes
in
> > Dolphin itself?
> >
>
> I need an additonal bit set in the class style for OpenGL views (CS_OWNDC)
> and overrode #winClassStyle.   My understanding is that the View subclass
> must be registered in order for this style to take affect.

Yes, that makes sense. It is indeed necessary to register a different window
class if you want different attributes than the standard DolphinWindow
class.

Regards

Blair