<serious> Pretty interesting question ..

Is it possible to Ctype a control to its actual type without knowing in advace at run time ..

For Example

dim objcontrol as Object

ObjControl = new Label

Ctype(ObjControl, Label).text ="blah" ' its fine ..

but is it possible to do this ..

Ctype(ObjControl, typeof(ObjControl)).text ... something like this since in the above example I had to know in advance that I was Ctyping a label while in the latter example I do not care what control it is just Ctype it to whatever type it has, that way following code would be possible to achieve.

dim objcontrol as Object

ObjControl = new Label

Ctype(ObjControl, Typeof(ObjControl)).text ="blah" ' its fine ..

ObjControl = new TextBox

Ctype(ObjControl, Typeof(ObjControl)).text ="blah" ' its fine ..

without actually knowing the type of the control ....

This situation would only ever arise if you had neglected other parts of your program so badly that you can no longer take advantage of OOP. You'd have to be an especially gifted bad programmer to mangle an app like that. I can only salute you from afar.

Send us a postcard wont you? :D

Sorry.

I tried, but I couldn't come up with a ctype method to do what you request.

Could you use the following?

VB Code:

Public Sub TEST_THIS(ByRef mControl As Control, ByVal mText As String)
        mControl.Text = mText
    End Sub

Or would you like something else.

These questions should be posted in the VB forum ..

Maybe even VB.NET seeing as CType() doesn't exist in classic VB.

Sorry .. :blush:

Is this the passed "sender" object of an event procedure?

What's the point? You're casting so that you can access specific members of that type, but if you don't know what the type is then how do you know what the members are? If you know that the object is a control then just cast it as a Control, from which all controls inherit their Text property anyway.

Anyway, you can't use GetType in that situation because that returns an instance of the Type class and not a Type.

Quote:

---

Originally Posted by jmcilhinney

What's the point? You're casting so that you can access specific members of that type, but if you don't know what the type is then how do you know what the members are? If you know that the object is a control then just cast it as a Control, from which all controls inherit their Text property anyway.

Anyway, you can't use GetType in that situation because that returns an instance of the Type class and not a Type.

---

actually, no. Lets say you were looping through all your controls on a web page for assigning them text based on the language selected by user.

Now textbox, label, button all have text property and option strict is on. One way to assign text would be something like this ..

For each control as control in mycontrols

if typeof control is textbox then
ctype(control,textbox).text = "blah"
end if


if typeof control is button then
ctype(control,button).text = "blah"
end if


if typeof control is label then
ctype(control,label).text = "blah"
end if

Next

But if you see in the end all we're doing is setting the text property so I should not have to check the type of the control in Ctype. All I want to say is something like this ..

For each l_control as control in mycontrols

ctype(l_control,"Whatever type it is at the moment for l_control").text = "blah"

Next

and it should work ...

Quote:

---

Originally Posted by wossname

This situation would only ever arise if you had neglected other parts of your program so badly that you can no longer take advantage of OOP. You'd have to be an especially gifted bad programmer to mangle an app like that. I can only salute you from afar.

Send us a postcard wont you? :D

---

wossy, see my above post ..

Well you can't do that because while each of those properties may have the same name they are not the same property, because, in the case of Web controls, they are each members of different classes. Just because you think it should work because it is convenient for you has no bearing on reality. If they are all derived from a common base class and the property is inherited from that class, like System.Windows.Forms.Control.Text, then you can cast each object as a Control and access the common property that way. Otherwise you have to live by the rules of OOP and cast each object as the appropriate type. Your only other option is to turn Option Strict Off and use late-binding, but I think you know what the concensus is about that.

Quote:

---

Originally Posted by jmcilhinney

Well you can't do that because while each of those properties may have the same name they are not the same property, because, in the case of Web controls, they are each members of different classes. Just because you think it should work because it is convenient for you has no bearing on reality. If they are all derived from a common base class and the property is inherited from that class, like System.Windows.Forms.Control.Text, then you can cast each object as a Control and access the common property that way. Otherwise you have to live by the rules of OOP and cast each object as the appropriate type. Your only other option is to turn Option Strict Off and use late-binding, but I think you know what the concensus is about that.

---

whatever you said here is something I am very well aware of .. what I asked originally if there was a way ....

And you've been told that there isn't a way because it defies logic, even if it seems convenient, and yet you still post that it SHOULD work. Well, the fact is that it doesn't work because it SHOULDN'T work because it breaks the rules. What you could do is use Reflection to determine whether the object had a property named Text and, if so, set it that way. That would take just as much code as the other way though, unless you had a large number of types to check for.

Rather than being coy how about telling us what you want to achieve? Save settings?

This n00b wants to know why you need to use Ctype if you already know a control's type?
If you know that it is going to be a textbox why not just say textbox1.text = "blah"?

Must be something I don't know here. ^^

Quote:

---

Originally Posted by Kal_Torak

This n00b wants to know why you need to use Ctype if you already know a control's type?
If you know that it is going to be a textbox why not just say textbox1.text = "blah"?

Must be something I don't know here. ^^

---

I ain't no noobe dude. What I am saying here makes sense if you think about it ... Although it appears that its not possible, however, I am simple saying CType should be intelligent enough to CAST the control to whatever type it is rather than us having to explicitly specify the type of the control.

OMG no it shouldn't.

The control is already of the type that it is :afrog:

Laugh at me if this is stupid, but what's wrong with

VB Code:

For Each ctl As Control In myControls
    ctl.Text = "Blah"
Next

?

Quote:

---

Originally Posted by penagate

Laugh at me if this is stupid, but what's wrong with

VB Code:

For Each ctl As Control In myControls
    ctl.Text = "Blah"
Next

?

---

Won't work if Option Strict is ON. That is what is wrong with it ....

Quote:

---

Originally Posted by grilkip

OMG no it shouldn't.

The control is already of the type that it is :afrog:

---

Exactly, that is the point, if control is already of the type that I want it to be then why do I have to Ctype it to a specific type such as Label or Button ??

Because you don't know what type it is, therefore you cannot, with 100% certainity, know its interface.

If you are using .NET 2, you might use the TryCast operator

VB Code:

For Each ctl As Control In myControls
    Dim txtBox As TextBox = TryCast(ctl, TextBox)
    If (txtBox IsNot Nothing) Then txtBox.Text = "blah"
Next

if I understood it right.

Quote:

---

Originally Posted by penagate

Because you don't know what type it is, therefore you cannot, with 100% certainity, know its interface.

If you are using .NET 2, you might use the TryCast operator

VB Code:

For Each ctl As Control In myControls
    Dim txtBox As TextBox = TryCast(ctl, TextBox)
    If (txtBox IsNot Nothing) Then txtBox.Text = "blah"
Next

if I understood it right.

---

That's the thing, I do not want to know its type. I guess its not possible in .NET 1.1

Sounds like you are trying to create run-time polymorphism, which is not a feature in .NET 2003. It does have it's uses.

What you're talking about is late-binding, plain and simple. You're trying to tell the compiler that you won't know what type the object is until run time but you still want to set its Text property, but the compiler can't let you do that because it has to know at design time that the object has a Text property n order to compile the code. If you turn Option Strict Off then the compiler will allow late-binding because it doesn't check at compile time whether the type has the specified member. The thing is, you're saying that you should be able to use CType, but if you're going to go ahead and use the Text property no matter what type it is anyway, why would you even try to use CType? If the object has a Text property then it will work without CType and if it doesn't then it will throw an exception. CType is to cast to a specific type that you know at design time. Leaving it until run time to determine a type is called late-binding.

Yah, I don't want to start a debate over the merits of Option Strict, which no doubt has been done before (although personally I haven't a clue what other effects turning it off has), but IMO there is nothing wrong with late-binding per se; situations like this are what it's for...

So what you're saying is basically this

VB Code:

For Each ctl As Control In myControls
    Try
        ctl.Text = "Blah"
    Catch ex As Exception
    End Try
Next

with Option Strict off, is the best solution?

If Option Strict is such a big deal then I can't believe there isn't a more elegant method of achieving it with Option Strict on.

I think this is actually something that MS is working on (for a future .NET release... past 2005)... if I understand you right.. let me see if I can find the channel 9 video and you can watch it and see if its the same thing

here.

its actually funny to watch too because these guys are VB superstars.. yet they have a little trouble coding in the video :)

http://channel9.msdn.com/Showpost.aspx?postid=116702

Quote:

---

Originally Posted by spoiledkid

I ain't no noobe dude. What I am saying here makes sense if you think about it ... Although it appears that its not possible, however, I am simple saying CType should be intelligent enough to CAST the control to whatever type it is rather than us having to explicitly specify the type of the control.

---

Not sure.. but I think perhaps he was calling himself a noob???

I'm watching the video you linked to Matt. Nice to see their exceptions are as slow as mine :)

exceptions are generally only slow in debug mode on the first exception created.. they run fast when compiled in release mode and run from the EXE

Quote:

---

Originally Posted by kleinma

Not sure.. but I think perhaps he was calling himself a noob???

---

Right you are ;)

While KalsIQ <= lownumber
kal = n00b
next

Jimmy is right you are esentially late binding because since you don't know what type of control you are going to use until design time then the compiler can't know either so it can't check it for bugs until runtime.

But you could use reflection to check the control for a text property and set it. It don't know if that counts as early or late binding - I assume it is late but it is a safe check of the property.

VB Code:

For Each ctrl As Control In MyControls
 
            If TypeOf (ctrl) Is Button Or TypeOf (ctrl) Is Label Or TypeOf (ctrl) Is TextBox Then
                Dim t As Type = ctrl.GetType
                Dim pi As Reflection.PropertyInfo = t.GetProperty("Text")
                If Not pi Is Nothing Then
                    pi.SetValue(ctrl, "test", Nothing)
                End If
            End If
 
        Next

Quote:

---

Originally Posted by Edneeis

Jimmy is right you are esentially late binding because since you don't know what type of control you are going to use until design time then the compiler can't know either so it can't check it for bugs until runtime.

But you could use reflection to check the control for a text property and set it. It don't know if that counts as early or late binding - I assume it is late but it is a safe check of the property.

VB Code:

For Each ctrl As Control In MyControls
 
            If TypeOf (ctrl) Is Button Or TypeOf (ctrl) Is Label Or TypeOf (ctrl) Is TextBox Then
                Dim t As Type = ctrl.GetType
                Dim pi As Reflection.PropertyInfo = t.GetProperty("Text")
                If Not pi Is Nothing Then
                    pi.SetValue(ctrl, "test", Nothing)
                End If
            End If
 
        Next

---

That's not late-binding because you know at design time the type of every object you are referencing. What you're doing in not late-binding just like using If statements to check the run-time type and execute the correct cast accordingly is not late-binding.

Couldn't you just do that without the If() block ? Seems a bit pointless to me if you are looking for the property anyway.

Quote:

---

Originally Posted by jmcilhinney

That's not late-binding because you know at design time the type of every object you are referencing. What you're doing in not late-binding just like using If statements to check the run-time type and execute the correct cast accordingly is not late-binding.

---

But isn't Reflection inheritly late bound or no? I mean there is no way for the compiler to check the metadata until runtime.

Using Reflection is similar to just using If statements to determine how to cast in that what you are saying is this is how to check whether a certain member is present and this is how to behave depending on what is found, whereas late-binding is saying just assume that a certain member is present and hope for the best, without being given any specific reason to believe that that member will actually be there.

I disagree Latebind (IMO) has more to do with determining the type at designtime or not using strongly typed objects. For instance the following code is still late binding even though it's logic is not incorrect:

VB Code:

Dim o As Object=New Form()
o.Show()

Since I declare the variable as Object then it will still 'LateBind' to a form at runtime but there is more overhead in determining it.

Is this not correct?

So using reflection and some weak polymorphing technics seem to be in the same vein as that example. They wait until runtime to infer the type, because Reflection never really casts the object. Well I don't know if Reflection is late binding or not but it works and works well.

I guess it depends on your definition of late-binding. According to the help/MSDN, having Option Strict turned On disallows late-binding, but you can quite happlily use Reflection with Option Strict turned On. As far as I'm concerned, late-binding means that the compiler doesn't know what type an object is when the code is compiled. Using Reflection has no bearing on this because using it doesn't mean that the compiler is in any doubt about any of the type of any of the objects being used. That's basically because of the existence of the Type class. You can create an instance of the Type class from any object and then use the members of the Type instance to determine various things about the original object. Because you are working with a Type instance and not the original object you are in no doubt about what members are available to you.

You can use Reflection to achieve late binding. That doesn't mean it IS late binding.

Quote:

---

Originally Posted by penagate

You can use Reflection to achieve late binding. That doesn't mean it IS late binding.

---

This doesn't make any sense to me :)

Ok I think I see what you are saying Jimmy.