Interfaces, hidden windows and fixed string pointers

[Lobo]

Hi Dan,

I have three questions for you:

1) Recently I had a real problem. I started building a class that would
receive a TextBox and a CommandButton controls. Then, I would set their
references to two private variables that used the 'WithEvents' keyword to
handle their events. Well, these worked just fine, but, it just doesn't fit
when the controls I'm trying to pass by are part of an array. It seems that
VB implements/inherits an interface to the controls that are part of an
array to get the 'Index' parameter on the events, besides the other features
of a collection. So, this error comes up: Error 459 - 'Object or class does
not support the set of events'. I've tried to figure it out without any
success. Any idea??

2) How much do you know about those hidden windows that VB creates (their
classes names: "OleDdeWndClass 0x########", "OleMainThreadWndClass
0x########", "VBMsoStdCompMgr", "VBBubbleRT6", "ThunderRT6Main",
"VBFocusRT6")? 'Cause I know just a little... Do you know where we can find
some information about them? (it seems that MSDN doesn't have too much thing
about it)

3) I was trying to figure out how the strings are handled in VB. The
variable-length string was just straightforward: using 'VarPtr' function you
get the pointer to where the real data is stored (just the same pointer you
would get using 'StrPtr' function), and, the string is allocated in a new
place every time you make a change to it. So, I thought that the
fixed-length string would be just the same, with the difference that the
pointer where the real data stands would never change. But, it was not like
that. With the 'StrPtr' I always can get the data but its pointer is always
changing and couldn't figure out how to get this one only by using the
'VarPtr' function... Can you give me the light?? (Note, this is just a
matter of understanding some VB's internals)

Thanks a lot,
Lobo.
Soon: VBFX - http://www.fatorx.com.br

[Dan Appleman]

Lobo wrote:

> Hi Dan,
>
> I have three questions for you:
>
> 1) Recently I had a real problem. I started building a class that would
> receive a TextBox and a CommandButton controls. Then, I would set their
> references to two private variables that used the 'WithEvents' keyword to
> handle their events. Well, these worked just fine, but, it just doesn't fit
> when the controls I'm trying to pass by are part of an array. It seems that
> VB implements/inherits an interface to the controls that are part of an
> array to get the 'Index' parameter on the events, besides the other features
> of a collection. So, this error comes up: Error 459 - 'Object or class does
> not support the set of events'. I've tried to figure it out without any
> success. Any idea??
>

Thou shalt not pass references to controls as parameters to classes. I've heard
of all sorts of problems when
people do this.
I know that's not the answer you want to hear, but I really would suggest you
reevaluate your design.

>
> 2) How much do you know about those hidden windows that VB creates (their
> classes names: "OleDdeWndClass 0x########", "OleMainThreadWndClass
> 0x########", "VBMsoStdCompMgr", "VBBubbleRT6", "ThunderRT6Main",
> "VBFocusRT6")? 'Cause I know just a little... Do you know where we can find
> some information about them? (it seems that MSDN doesn't have too much thing
> about it)
>

None of these are documented, but I know a little bit about a couple of them.
ThunderRT6Main is the main hidden window for your VB application (every VB
application has one - it's the main
top level application window - see my Win32 API book for a bit more about this
window).
OleMainThreadWndClass is one of the windows that is used to marshal COM method
calls. Marshaling on a local system is handled internally by a sent or posted
message.
I suspect OleDdeWndClass is the window used for DDE messages (DDE is also a
SendMessage/PostMessage based protocol under the hood).
I have no idea what the other two are. VBBubbleRT6 seems especially interesting.
Anyone have an idea?

>
> 3) I was trying to figure out how the strings are handled in VB. The
> variable-length string was just straightforward: using 'VarPtr' function you
> get the pointer to where the real data is stored (just the same pointer you
> would get using 'StrPtr' function), and, the string is allocated in a new
> place every time you make a change to it. So, I thought that the
> fixed-length string would be just the same, with the difference that the
> pointer where the real data stands would never change. But, it was not like
> that. With the 'StrPtr' I always can get the data but its pointer is always
> changing and couldn't figure out how to get this one only by using the
> 'VarPtr' function... Can you give me the light?? (Note, this is just a
> matter of understanding some VB's internals)
>

Almost everything you ask here is covered in incredible detail in my previous
book "Dan Appleman's Win32 API Puzzle Book and Tutorial for VB Programmers". In
that book you'll learn all about VarPtr, StrPtr and the magic of BSTR's (the OLE
subsystem strings which VB uses). Conversions from Unicode and ANSI, etc.
As for StrPtr on fixed strings - I'm pretty sure it converts your fixed string
into a temporary dynamic string before returning the pointer - that's why it's
in a different memory location each time.

Dan

[Mark Russo]

Dan Appleman <dan@desaware.com> wrote:
...

>Thou shalt not pass references to controls as parameters to classes. I've
heard
>of all sorts of problems when
>people do this.

Dan - I've used this technique frequently without a problem. Can you expand
on why this is a bad idea?

Thanks.

Mark

[Lobo]

Thank you Dan.

I've heard somewhere that the VBBubbleRT6 window is the VB tooltip window.
I've just tested with a label on a form that has a tooltiptext property set
to some text and so I used the FindWindow API to search for the window with
the "VBBubbleRT6" class name and get the window title with the GetWindowText
function, and... voila! That was my tooltip window.

The VBFocusRT6 window seemed to me like a focus manager to windowless
controls (that's because I found it just in the ocasion of building some of
these lightweight controls with a friend of mine, when we were asking
ourselves how does VB treat this thing of sending the focus to the right
control, even being a windowless control). But, now, I'm not sure about it
anymore since it appears in the Spy++ even if you have a clean form (without
any controls).

About the first (question/answer) one: OK. I can follow your advice and try
another approach here. But, even if I don't use that approach in this case,
I'm too curious to know about it. Don't you know what goes under the hood
when we have an array of controls? What does VB do to get the 'Index'
parameter to all the events? Do you know something about it? I would
appreciate a lot if you (or someone else) gave some light here.

Thanks again!!


Lobo.
Soon: VBFX - http://www.fatorx.com.br


Dan Appleman <dan@desaware.com> wrote in message
news:38F41A16.AC2DB493@desaware.com...
>
>
> Lobo wrote:
>
> > Hi Dan,
> >
> > I have three questions for you:
> >
> > 1) Recently I had a real problem. I started building a class that would
> > receive a TextBox and a CommandButton controls. Then, I would set their
> > references to two private variables that used the 'WithEvents' keyword
to
> > handle their events. Well, these worked just fine, but, it just doesn't
fit
> > when the controls I'm trying to pass by are part of an array. It seems
that
> > VB implements/inherits an interface to the controls that are part of an
> > array to get the 'Index' parameter on the events, besides the other
features
> > of a collection. So, this error comes up: Error 459 - 'Object or class
does
> > not support the set of events'. I've tried to figure it out without any
> > success. Any idea??
> >
>
> Thou shalt not pass references to controls as parameters to classes. I've
heard
> of all sorts of problems when
> people do this.
> I know that's not the answer you want to hear, but I really would suggest
you
> reevaluate your design.
>
> >
> > 2) How much do you know about those hidden windows that VB creates
(their
> > classes names: "OleDdeWndClass 0x########", "OleMainThreadWndClass
> > 0x########", "VBMsoStdCompMgr", "VBBubbleRT6", "ThunderRT6Main",
> > "VBFocusRT6")? 'Cause I know just a little... Do you know where we can
find
> > some information about them? (it seems that MSDN doesn't have too much
thing
> > about it)
> >
>
> None of these are documented, but I know a little bit about a couple of
them.
> ThunderRT6Main is the main hidden window for your VB application (every VB
> application has one - it's the main
> top level application window - see my Win32 API book for a bit more about
this
> window).
> OleMainThreadWndClass is one of the windows that is used to marshal COM
method
> calls. Marshaling on a local system is handled internally by a sent or
posted
> message.
> I suspect OleDdeWndClass is the window used for DDE messages (DDE is also
a
> SendMessage/PostMessage based protocol under the hood).
> I have no idea what the other two are. VBBubbleRT6 seems especially
interesting.
> Anyone have an idea?
>
> >
> > 3) I was trying to figure out how the strings are handled in VB. The
> > variable-length string was just straightforward: using 'VarPtr' function
you
> > get the pointer to where the real data is stored (just the same pointer
you
> > would get using 'StrPtr' function), and, the string is allocated in a
new
> > place every time you make a change to it. So, I thought that the
> > fixed-length string would be just the same, with the difference that the
> > pointer where the real data stands would never change. But, it was not
like
> > that. With the 'StrPtr' I always can get the data but its pointer is
always
> > changing and couldn't figure out how to get this one only by using the
> > 'VarPtr' function... Can you give me the light?? (Note, this is just a
> > matter of understanding some VB's internals)
> >
>
> Almost everything you ask here is covered in incredible detail in my
previous
> book "Dan Appleman's Win32 API Puzzle Book and Tutorial for VB
Programmers". In
> that book you'll learn all about VarPtr, StrPtr and the magic of BSTR's
(the OLE
> subsystem strings which VB uses). Conversions from Unicode and ANSI, etc.
> As for StrPtr on fixed strings - I'm pretty sure it converts your fixed
string
> into a temporary dynamic string before returning the pointer - that's why
it's
> in a different memory location each time.
>
> Dan
>
>

[Dan Appleman]

Unfortunately, I don't have anything specific I can point to. It just seems less
robust than other approaches. For example: I was recently talking to someone who
was having all sorts of problems getting his program to work properly. When he
stopped passing a form as a parameter, everything worked fine.
I think you're fairly safe as long as you're dealing with private classes or
modules in an application. But once the classes are public, things seem to
become less stable - especially with the built-in controls. Perhaps someone here
has more detailed information.

Dan

Mark Russo wrote:

> Dan Appleman <dan@desaware.com> wrote:
> ..
>
> >Thou shalt not pass references to controls as parameters to classes. I've
> heard
> >of all sorts of problems when
> >people do this.
>
> Dan - I've used this technique frequently without a problem. Can you expand
> on why this is a bad idea?
>
> Thanks.
>
> Mark

[Eric S. Ford]

I recently came across a similar design "anomaly" where I work. I critiqued
it by pointing out that in a tiered design, forms are part of the presentation
layer while the classes, generally, are part of the business layer. It is
far easier to understand having a reference to a business object within a
form that "presents" that object to a user than it is to have a reference
to a form within the business object. Kind of "cart before the horse."

As it was here, the programmer had declared a form variable WithEvents in
the class then had the class raise its own events to whenever it received
events from the form (this is a brain twister just describing it). It seems
so much more intuitive to let the form, through its controls, operate on
the business object and then the object raises its events, as necessary,
in response.

Eric

Dan Appleman <dan@desaware.com> wrote:
>Unfortunately, I don't have anything specific I can point to. It just seems
less
>robust than other approaches. For example: I was recently talking to someone
who
>was having all sorts of problems getting his program to work properly. When
he
>stopped passing a form as a parameter, everything worked fine.
>I think you're fairly safe as long as you're dealing with private classes
or
>modules in an application. But once the classes are public, things seem
to
>become less stable - especially with the built-in controls. Perhaps someone
here
>has more detailed information.
>
>Dan
>
>Mark Russo wrote:
>
>> Dan Appleman <dan@desaware.com> wrote:
>> ..
>>
>> >Thou shalt not pass references to controls as parameters to classes.
I've
>> heard
>> >of all sorts of problems when
>> >people do this.
>>
>> Dan - I've used this technique frequently without a problem. Can you
expand
>> on why this is a bad idea?
>>
>> Thanks.
>>
>> Mark
>