Interfaces, hidden windows and fixed string pointers


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Interfaces, hidden windows and fixed string pointers

  1. #1
    Lobo Guest

    Interfaces, hidden windows and fixed string pointers

    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


    Share on Google+

  2. #2
    Dan Appleman Guest

    Re: Interfaces, hidden windows and fixed string pointers



    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


    Share on Google+

  3. #3
    Mark Russo Guest

    Re: Interfaces, hidden windows and fixed string pointers


    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
    Share on Google+

  4. #4
    Lobo Guest

    Re: Interfaces, hidden windows and fixed string pointers

    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
    >
    >



    Share on Google+

  5. #5
    Dan Appleman Guest

    Re: Interfaces, hidden windows and fixed string pointers

    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


    Share on Google+

  6. #6
    Eric S. Ford Guest

    Re: Interfaces, hidden windows and fixed string pointers


    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

    >


    Share on Google+

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center