Re: Passing an object name through a variable

[mrfelis]

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

[Mike]

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

[mrfelis]

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

[Mike]

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

[Julia Lerman]

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

[Mike]

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

[Julia Lerman]

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

[mrfelis]

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

[mrfelis]

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

[Mike]

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