Re: Passing an object name through a variable


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 10 of 10

Thread: Re: Passing an object name through a variable

  1. #1
    mrfelis Guest

    Re: Passing an object name through a variable

    Three choices:
    1. Declare an object variable of the type required.
    2. Declare a generic object variable of the type "Object"
    3. Declare a variant type variable.

    Here's samples of how to do it:
    Private Sub Command3_Click()
    Dim oT As TextBox

    Set oT = Text1
    oT.Text = "TextBox"
    End Sub

    Private Sub Command1_Click()
    Dim o As Object

    Set o = Text1
    o.Text = "Object"
    End Sub


    Private Sub Command2_Click()
    Dim v As Variant

    Set v = Text1
    v.Text = "Variant"

    End Sub


    You can also pass the object to a Sub or Function:

    Private Sub PassTextBox( oT as TextBox)
    oT.Text="PassTextBox"
    End Sub

    Private Sub Command4_Click()
    PassTextBox Text1
    End Sub

    Please note that while I'm using a Textbox control as an object to pass
    around inside the project, you can't pass the same to an Active X DLL (I
    assume but haven't tried the same in a control). This is because VB wraps
    controls inside its own extender library. You get a Type Mismatch Error (13)
    if you try to.

    cya,
    mrfelis


    Snip wrote in message <38c8cf84$1@news.devx.com>...
    >
    >I need to be able to pass the name of an object into a variable and the use
    >the variable to alter that objects properties...
    >
    >eg.
    >
    >Variable1 = ActMod1.Name
    >
    >Variable1.value = 15
    >variable1.ID = 0012
    >
    >etc.
    >
    >Does anyone know how to do this???
    >




  2. #2
    Mike Guest

    Re: Passing an object name through a variable


    mrfelis,

    The textbox does not get wrapped by the Extender as it is a built in control.
    I don't think there would be any problem passing it into a dll.

    >>You get a Type Mismatch Error (13)


    I know this error well. It only occurred when compiled and took me 4 hours
    to find (grrr). It only occurs when you pass a reference to a control out
    of a usercontrol project

    Mike

    >Please note that while I'm using a Textbox control as an object to pass
    >around inside the project, you can't pass the same to an Active X DLL (I
    >assume but haven't tried the same in a control). This is because VB wraps
    >controls inside its own extender library. You get a Type Mismatch Error

    (13)
    >if you try to.
    >
    >cya,
    >mrfelis



  3. #3
    mrfelis Guest

    Re: Passing an object name through a variable


    Mike wrote in message <38ff2658$1@news.devx.com>...
    >
    >mrfelis,
    >
    >The textbox does not get wrapped by the Extender as it is a built in

    control.
    >I don't think there would be any problem passing it into a dll.


    Intrinsic controls aren't wrapped... I should have known that....

    >>>You get a Type Mismatch Error (13)

    >
    >I know this error well. It only occurred when compiled and took me 4 hours
    >to find (grrr). It only occurs when you pass a reference to a control out
    >of a usercontrol project
    >

    I get the error every time I tired passing Tidestone's Formula 1 spreadsheet
    control to a DLL. The error occurred on my system when ever it ran with full
    compile.

    I ended up generating events in the DLL the client had to respond to. The
    client was responsible with interacting with the control and changing
    specific parameters that were passed ByRef back to the DLL.

    You might consider something similar? (Assuming you still have this problem)

    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam



  4. #4
    Mike Guest

    Re: Passing an object name through a variable


    I had to do a similar thing, but with properties and methods. I had a 'Master'
    control on an MDI form and a 'Slave' on each form. The master control kept
    all central properties. I wanted to do something like this:

    Slave.Master.SomeProperty

    But it gave me the type mismatch error. So in the end I duplicated the relevant
    properties and methods:

    Slave.SomeProperty

    or I just did this (which I think is wrong as controls should not be public
    properties of a form, but it worked)

    MDIForm.Master.SomeProperty



    Mike


    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >
    >Mike wrote in message <38ff2658$1@news.devx.com>...
    >>
    >>mrfelis,
    >>
    >>The textbox does not get wrapped by the Extender as it is a built in

    >control.
    >>I don't think there would be any problem passing it into a dll.

    >
    >Intrinsic controls aren't wrapped... I should have known that....
    >
    >>>>You get a Type Mismatch Error (13)

    >>
    >>I know this error well. It only occurred when compiled and took me 4 hours
    >>to find (grrr). It only occurs when you pass a reference to a control out
    >>of a usercontrol project
    >>

    >I get the error every time I tired passing Tidestone's Formula 1 spreadsheet
    >control to a DLL. The error occurred on my system when ever it ran with

    full
    >compile.
    >
    >I ended up generating events in the DLL the client had to respond to. The
    >client was responsible with interacting with the control and changing
    >specific parameters that were passed ByRef back to the DLL.
    >
    >You might consider something similar? (Assuming you still have this problem)
    >
    >~~~
    >C'Ya,
    >mrfelis
    >mrfelis@yahoo.NOSPAM.com
    >just remove the spam
    >
    >



  5. #5
    Julia Lerman Guest

    Re: Passing an object name through a variable

    Hey guys: I wonder if this might be related to a problem that took me 7 hours to
    deal with (I get a bigger grrr...)

    This, as with your controls, only showed up in the compiled exe and threw an error
    about the control being disconnected from its clients. I spent eons messing around
    with regedit, because I thought it was related to the fact that I had modified the
    control of an ocx (with multiple controls) that had already been deployed. But here
    was the cause (totally bizarre)...

    I had ControlA that was like a little mini form. ControlA was being embedded into a
    generic form at run time using createcontrol. ControlA also happens to contain
    another control (a grid control that I designed to suit the purposes of this
    project). When loading up the generic form with ControlA in it, I populate the grid
    control (controlB) in the code of ControlA. There are a whole bunch of calls:

    ControlA.PropertyX = "blah"
    ControlA.PropertyY="blahblah"
    ControlA.SetPropertyZ "123"

    whatever

    Anyway one of these subs that I called changed the alignment of the header row of
    the grid. And by tracing it with about 5,000 messages (since I couldn't generate
    the error in design mode, I had to run it from the exe) I finally found that this
    was the line that was killing me. It was in side of a subroutine "fillgrid". If I
    took it out of "fillgrid" and put it into the 'load' routine infront of the
    fillgrid, then it was ok. If I put it after fill grid it wasn't ok.

    Totally nuts.

    Does this sound familiar?

    Julie

    Mike wrote:

    > I had to do a similar thing, but with properties and methods. I had a 'Master'
    > control on an MDI form and a 'Slave' on each form. The master control kept
    > all central properties. I wanted to do something like this:
    >
    > Slave.Master.SomeProperty
    >
    > But it gave me the type mismatch error. So in the end I duplicated the relevant
    > properties and methods:
    >
    > Slave.SomeProperty
    >
    > or I just did this (which I think is wrong as controls should not be public
    > properties of a form, but it worked)
    >
    > MDIForm.Master.SomeProperty
    >
    > Mike
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >
    > >Mike wrote in message <38ff2658$1@news.devx.com>...
    > >>
    > >>mrfelis,
    > >>
    > >>The textbox does not get wrapped by the Extender as it is a built in

    > >control.
    > >>I don't think there would be any problem passing it into a dll.

    > >
    > >Intrinsic controls aren't wrapped... I should have known that....
    > >
    > >>>>You get a Type Mismatch Error (13)
    > >>
    > >>I know this error well. It only occurred when compiled and took me 4 hours
    > >>to find (grrr). It only occurs when you pass a reference to a control out
    > >>of a usercontrol project
    > >>

    > >I get the error every time I tired passing Tidestone's Formula 1 spreadsheet
    > >control to a DLL. The error occurred on my system when ever it ran with

    > full
    > >compile.
    > >
    > >I ended up generating events in the DLL the client had to respond to. The
    > >client was responsible with interacting with the control and changing
    > >specific parameters that were passed ByRef back to the DLL.
    > >
    > >You might consider something similar? (Assuming you still have this problem)
    > >
    > >~~~
    > >C'Ya,
    > >mrfelis
    > >mrfelis@yahoo.NOSPAM.com
    > >just remove the spam
    > >
    > >



  6. #6
    Mike Guest

    Re: Passing an object name through a variable


    I have had this error before, but I can't remeber the situation. I think it
    was when the form that the control was loaded on was unloaded, but I still
    had a reference to the control.

    In your situation, at a guess, I would say it had something to with the order
    or way in which controls are created. If you have two controls on a form
    (or another UserControl), you can't be sure the other control is there for
    all events. You can't even be sure the form is there in some events. Maybe
    for the call you were making, it expected the control to be there.

    What did the function that failed do?

    Mike


    Julia Lerman <jlerman@thedatafarm.com> wrote:
    >Hey guys: I wonder if this might be related to a problem that took me 7

    hours to
    >deal with (I get a bigger grrr...)
    >
    >This, as with your controls, only showed up in the compiled exe and threw

    an error
    >about the control being disconnected from its clients. I spent eons messing

    around
    >with regedit, because I thought it was related to the fact that I had modified

    the
    >control of an ocx (with multiple controls) that had already been deployed.

    But here
    >was the cause (totally bizarre)...
    >
    >I had ControlA that was like a little mini form. ControlA was being embedded

    into a
    >generic form at run time using createcontrol. ControlA also happens to contain
    >another control (a grid control that I designed to suit the purposes of

    this
    >project). When loading up the generic form with ControlA in it, I populate

    the grid
    >control (controlB) in the code of ControlA. There are a whole bunch of calls:
    >
    >ControlA.PropertyX = "blah"
    >ControlA.PropertyY="blahblah"
    >ControlA.SetPropertyZ "123"
    >
    >whatever
    >
    >Anyway one of these subs that I called changed the alignment of the header

    row of
    >the grid. And by tracing it with about 5,000 messages (since I couldn't

    generate
    >the error in design mode, I had to run it from the exe) I finally found

    that this
    >was the line that was killing me. It was in side of a subroutine "fillgrid".

    If I
    >took it out of "fillgrid" and put it into the 'load' routine infront of

    the
    >fillgrid, then it was ok. If I put it after fill grid it wasn't ok.
    >
    >Totally nuts.
    >
    >Does this sound familiar?
    >
    >Julie
    >
    >Mike wrote:
    >
    >> I had to do a similar thing, but with properties and methods. I had a

    'Master'
    >> control on an MDI form and a 'Slave' on each form. The master control

    kept
    >> all central properties. I wanted to do something like this:
    >>
    >> Slave.Master.SomeProperty
    >>
    >> But it gave me the type mismatch error. So in the end I duplicated the

    relevant
    >> properties and methods:
    >>
    >> Slave.SomeProperty
    >>
    >> or I just did this (which I think is wrong as controls should not be public
    >> properties of a form, but it worked)
    >>
    >> MDIForm.Master.SomeProperty
    >>
    >> Mike
    >>
    >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >> >
    >> >Mike wrote in message <38ff2658$1@news.devx.com>...
    >> >>
    >> >>mrfelis,
    >> >>
    >> >>The textbox does not get wrapped by the Extender as it is a built in
    >> >control.
    >> >>I don't think there would be any problem passing it into a dll.
    >> >
    >> >Intrinsic controls aren't wrapped... I should have known that....
    >> >
    >> >>>>You get a Type Mismatch Error (13)
    >> >>
    >> >>I know this error well. It only occurred when compiled and took me 4

    hours
    >> >>to find (grrr). It only occurs when you pass a reference to a control

    out
    >> >>of a usercontrol project
    >> >>
    >> >I get the error every time I tired passing Tidestone's Formula 1 spreadsheet
    >> >control to a DLL. The error occurred on my system when ever it ran with

    >> full
    >> >compile.
    >> >
    >> >I ended up generating events in the DLL the client had to respond to.

    The
    >> >client was responsible with interacting with the control and changing
    >> >specific parameters that were passed ByRef back to the DLL.
    >> >
    >> >You might consider something similar? (Assuming you still have this problem)
    >> >
    >> >~~~
    >> >C'Ya,
    >> >mrfelis
    >> >mrfelis@yahoo.NOSPAM.com
    >> >just remove the spam
    >> >
    >> >

    >



  7. #7
    Julia Lerman Guest

    Re: Passing an object name through a variable

    Mike -
    Here are the calls (just the ones related to this problem) in the routine that fills
    out the form:

    The problem child is the setrowalign function. This just says set the alignment of
    row(0) to center.

    It was (along with setgridheight) originally part of the fillgrdSeive routine inside
    of the with/wend.

    It was at the end
    It didn't like these afterwards. However, you can see here that it makes sense to
    put the gridheight one at the end, as the height of the grid changes because of the
    rowheigh function.

    Anyway, it is solved, but there was no logic to the solution.

    Julie

    grdSieve.setGridHeight grdSieve.Height
    grdSieve.SetRowAlign 0, flexAlignCenterCenter
    fillgrdSieve

    It could have been a positioning thing. For example, maybe part of fillgrdSeive puts
    data into the header row, which is the one that SetRowAlign is working with. Maybe
    it didn't like me modifiying the alignment of the row after the fact. But that does
    not seem like an intelligent deduction - especially since the whole thing was fine
    within the IDE. I do not believe that there is any logic to the problem and solution
    - which is very hard as a programmer to accept!


    Julie

    Mike wrote:

    > I have had this error before, but I can't remeber the situation. I think it
    > was when the form that the control was loaded on was unloaded, but I still
    > had a reference to the control.
    >
    > In your situation, at a guess, I would say it had something to with the order
    > or way in which controls are created. If you have two controls on a form
    > (or another UserControl), you can't be sure the other control is there for
    > all events. You can't even be sure the form is there in some events. Maybe
    > for the call you were making, it expected the control to be there.
    >
    > What did the function that failed do?
    >
    > Mike
    >
    > Julia Lerman <jlerman@thedatafarm.com> wrote:
    > >Hey guys: I wonder if this might be related to a problem that took me 7

    > hours to
    > >deal with (I get a bigger grrr...)
    > >
    > >This, as with your controls, only showed up in the compiled exe and threw

    > an error
    > >about the control being disconnected from its clients. I spent eons messing

    > around
    > >with regedit, because I thought it was related to the fact that I had modified

    > the
    > >control of an ocx (with multiple controls) that had already been deployed.

    > But here
    > >was the cause (totally bizarre)...
    > >
    > >I had ControlA that was like a little mini form. ControlA was being embedded

    > into a
    > >generic form at run time using createcontrol. ControlA also happens to contain
    > >another control (a grid control that I designed to suit the purposes of

    > this
    > >project). When loading up the generic form with ControlA in it, I populate

    > the grid
    > >control (controlB) in the code of ControlA. There are a whole bunch of calls:
    > >
    > >ControlA.PropertyX = "blah"
    > >ControlA.PropertyY="blahblah"
    > >ControlA.SetPropertyZ "123"
    > >
    > >whatever
    > >
    > >Anyway one of these subs that I called changed the alignment of the header

    > row of
    > >the grid. And by tracing it with about 5,000 messages (since I couldn't

    > generate
    > >the error in design mode, I had to run it from the exe) I finally found

    > that this
    > >was the line that was killing me. It was in side of a subroutine "fillgrid".

    > If I
    > >took it out of "fillgrid" and put it into the 'load' routine infront of

    > the
    > >fillgrid, then it was ok. If I put it after fill grid it wasn't ok.
    > >
    > >Totally nuts.
    > >
    > >Does this sound familiar?
    > >
    > >Julie
    > >
    > >Mike wrote:
    > >
    > >> I had to do a similar thing, but with properties and methods. I had a

    > 'Master'
    > >> control on an MDI form and a 'Slave' on each form. The master control

    > kept
    > >> all central properties. I wanted to do something like this:
    > >>
    > >> Slave.Master.SomeProperty
    > >>
    > >> But it gave me the type mismatch error. So in the end I duplicated the

    > relevant
    > >> properties and methods:
    > >>
    > >> Slave.SomeProperty
    > >>
    > >> or I just did this (which I think is wrong as controls should not be public
    > >> properties of a form, but it worked)
    > >>
    > >> MDIForm.Master.SomeProperty
    > >>
    > >> Mike
    > >>
    > >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >> >
    > >> >Mike wrote in message <38ff2658$1@news.devx.com>...
    > >> >>
    > >> >>mrfelis,
    > >> >>
    > >> >>The textbox does not get wrapped by the Extender as it is a built in
    > >> >control.
    > >> >>I don't think there would be any problem passing it into a dll.
    > >> >
    > >> >Intrinsic controls aren't wrapped... I should have known that....
    > >> >
    > >> >>>>You get a Type Mismatch Error (13)
    > >> >>
    > >> >>I know this error well. It only occurred when compiled and took me 4

    > hours
    > >> >>to find (grrr). It only occurs when you pass a reference to a control

    > out
    > >> >>of a usercontrol project
    > >> >>
    > >> >I get the error every time I tired passing Tidestone's Formula 1 spreadsheet
    > >> >control to a DLL. The error occurred on my system when ever it ran with
    > >> full
    > >> >compile.
    > >> >
    > >> >I ended up generating events in the DLL the client had to respond to.

    > The
    > >> >client was responsible with interacting with the control and changing
    > >> >specific parameters that were passed ByRef back to the DLL.
    > >> >
    > >> >You might consider something similar? (Assuming you still have this problem)
    > >> >
    > >> >~~~
    > >> >C'Ya,
    > >> >mrfelis
    > >> >mrfelis@yahoo.NOSPAM.com
    > >> >just remove the spam
    > >> >
    > >> >

    > >



  8. #8
    mrfelis Guest

    Re: Passing an object name through a variable

    Mike,

    Sounds very much like the same problem.

    Mike wrote in message <39017c06$1@news.devx.com>...
    >
    >I had to do a similar thing, but with properties and methods. I had a

    'Master'
    >control on an MDI form and a 'Slave' on each form. The master control kept
    >all central properties. I wanted to do something like this:
    >
    >Slave.Master.SomeProperty


    VB claims to expose an Object property of a wrapped control which is the
    actual object
    being wrapped. Have you tried any combinations of this? I did try it and
    found it didn't
    help myself.


    ><snip>
    >or I just did this (which I think is wrong as controls should not be public
    >properties of a form, but it worked)
    >
    >MDIForm.Master.SomeProperty


    I agree. Public controls lead to spaghetti code.
    >
    >Mike
    >

    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam



  9. #9
    mrfelis Guest

    Re: Passing an object name through a variable

    Julie,

    I'm afraid I'm not going to be able to help out much with this one as I
    haven't taken the time to work with custom controls yet.

    There is something I would check for if I were working on this problem
    though. Based on the description of the error, I'd look for a way to log the
    connect/disconnect events for the control.

    For an Add-In this can be done by adding logging code to the
    IDTExtensibility_OnConnection and IDTExtensibility_OnDisconnection
    procedures that are created when you implement the IDTExtensibility
    interface.

    I'm not sure if this can be done with controls.

    Hope this helps.

    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam


    Julia Lerman wrote in message <39037436.F28A49FD@thedatafarm.com>...
    >Hey guys: I wonder if this might be related to a problem that took me 7

    hours to
    >deal with (I get a bigger grrr...)
    ><snip>
    >Anyway one of these subs that I called changed the alignment of the header

    row of
    >the grid. And by tracing it with about 5,000 messages (since I couldn't

    generate
    >the error in design mode, I had to run it from the exe) I finally found

    that this
    >was the line that was killing me. It was in side of a subroutine

    "fillgrid". If I
    >took it out of "fillgrid" and put it into the 'load' routine infront of the
    >fillgrid, then it was ok. If I put it after fill grid it wasn't ok.
    >
    >Totally nuts.
    >
    >Does this sound familiar?
    >





  10. #10
    Mike Guest

    Re: Passing an object name through a variable


    If you dim a control inside a control project, you get the object (unrapped)
    you are talking out. But if you dim a control in the exe project that references
    the control project, you get the extended control. So if you pass out the
    value you get a type mismatch. I'm sure you know this, I am just reiterating.

    But the problem is that you can't do this in the exe:

    Dim X as MyControl.Object

    If you go completely late bound it will work, but this is a bit of a hack

    Mike

    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >Mike,
    >
    >Sounds very much like the same problem.
    >
    >Mike wrote in message <39017c06$1@news.devx.com>...
    >>
    >>I had to do a similar thing, but with properties and methods. I had a

    >'Master'
    >>control on an MDI form and a 'Slave' on each form. The master control kept
    >>all central properties. I wanted to do something like this:
    >>
    >>Slave.Master.SomeProperty

    >
    >VB claims to expose an Object property of a wrapped control which is the
    >actual object
    >being wrapped. Have you tried any combinations of this? I did try it and
    >found it didn't
    >help myself.
    >
    >
    >><snip>
    >>or I just did this (which I think is wrong as controls should not be public
    >>properties of a form, but it worked)
    >>
    >>MDIForm.Master.SomeProperty

    >
    >I agree. Public controls lead to spaghetti code.
    >>
    >>Mike
    >>

    >~~~
    >C'Ya,
    >mrfelis
    >mrfelis@yahoo.NOSPAM.com
    >just remove the spam
    >
    >



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