How to cast a Form

[Just Me]

I have two forms. Each contains a property, say Prop.

I do
Public FormBeingUsed as Form
..
..
..
Then I do
FormBeingUsed= Form1
or maybe
FormBeingUsed=Form2
..
..
..
then I want to do
FormBeingUsed.Prop=123

Of course, because Form does not have a property Prop the compiler complains

Is there a good way to do this?


Thanks

 

[Herfried K. Wagner [MVP]]

I have two forms. Each contains a property, say Prop.

I do
Public FormBeingUsed as Form
.
.
.
Then I do
FormBeingUsed= Form1
or maybe
FormBeingUsed=Form2
.
.
.
then I want to do
FormBeingUsed.Prop=123

Of course, because Form does not have a property Prop the compiler
complains

Is there a good way to do this?

\\\
Public Interface IUsable
Property Used As Boolean
End Interface

Public Class Form1
Inherits Form
Implements IUsable

Public Property Used() As Boolean Implements IUsable.Used
...
End Property
...
End Class

Public Class Form2
...
End Class
..
..
..
Dim f As IUsable
If...Then
f = New Form1()
Else
f = New Form2()
End If
f.Used = True
///

Another approach would use a common base class that adds a 'Used' property
to the form class and from which 'Form1' and 'Form2' inherit.

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,

I have two forms. Each contains a property, say Prop.
Is there a good way to do this?

Polymorphism, one of the tenants of OO, is a good way to do this. You can
use either Class Inheritance or Interface Implementation to achieve this
Polymorphism.

' Class Inheritance

Public Class BaseForm
Inherits System.Windows.Forms.Form

Public Property Prop As Integer
...
End Class


Public Class Form1
Inherits BaseForm
...
End Class

Public Class Form2
Inherits BaseForm
...
End Class

Public FormBeingUsed as BaseForm

FormBeingUsed= Form1
FormBeingUsed.Prop=123

FormBeingUsed=Form2
FormBeingUsed.Prop=123

' Interface Implementation

Public Interface IProp

Public Property Prop As Integer
...
End Interface


Public Class Form1
Inherits System.Windows.Forms.Form
Implements IProp

Public Property Prop As Integer Implements IProp.Prop
...
End Class

Public Class Form2
Inherits System.Windows.Forms.Form
Implements IProp

Public Property Prop As Integer Implements IProp.Prop
...
End Class

Public FormBeingUsed as IProp

FormBeingUsed= Form1
FormBeingUsed.Prop=123

FormBeingUsed=Form2
FormBeingUsed.Prop=123


You could define Prop to be Overridable in BaseForm or define an
OnPropChanged method that the BaseForm.Prop.Set method calls when the value
changes if you need derived forms to know about the value of Prop
changing...

I would favor Class Inheritance over Interface Implementation as normally
Class Inheritance will produce less code.

Hope this helps
Jay

 

[Just Me]

Every once in a while I ask a question that results in especially
interesting answers.

Answers that not only solve but have some academically interesting value.

I think these answers both helped and stimulated.

Thanks

 

[Just Me]

What's going on below. It looks like late binding is used for sender.Index
since Object does not have an index property.

Private Sub HandleTool_Click(ByVal sender As Object, ByVal e As
System.EventArgs)
Dim Index As Integer = sender.Index

If so, why isn't that a solution to the problem I posted below?
That is, using: Public FormBeingUsed as Object

Thanks again


" Just Me" (e-mail address removed)> wrote in message

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,
It looks like late binding to me. Do you have Option Strict On at the top of
the source file?

I use Option Strict On at the top of every source file as I prefer compile
time errors over hard to track down run time errors.

Where I need to use late binding (such as COM interop with CDO), I isolate
the late binding to a small isolated module in the far corner of my app...

If so, why isn't that a solution to the problem I posted below?
That is, using: Public FormBeingUsed as Object

Declaring a variable as Object does not enable late binding, you need to use
Option Strict Off to enable late binding, when you use late binding you run
the risk (a potentially high risk) have having hard to track down run time
errors, instead of obvious compile time errors. Not to mention that late
binding is generally a couple of magnitudes slower then early binding...

Unfortunately Option Strict Off is the default under project properties. I
normally include Option Strict On (or Off) in each source file, so its
obvious to other developers (who may link to the file) that the file does or
does not intend on using late binding...

Hope this helps
Jay

 

[Just Me]

I do have Option Strict Off.
I didn't know late binding was possible.

Thanks for the info

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,
Late binding is possible, but it is not recommended.

I only use it in very select cases, which normally involves COM interop to
COM objects that are intended for VBScript (all parameters & properties are
type Object). Even then I try to isolate the late binding or encapsulate it
in classes where I have a heavy dose of DirectCasts (casting the property or
return value to its actual type).

Remember that late binding is inherently slower (as the method or property)
needs to be looked up at runtime rather compile time. These look ups can
fail, or an unexpected implicit conversion may occur which can create hard
to track down run time errors...

So in your case I strongly recommend using what Herfried & I initially
suggested!

Hope this helps
Jay

 

[Cor Ligthert]

Just Me,

I miss something in the answers

FormBeingUsed= new Form2
if typeof formbeingused Is Form2 then
Directcast(FormBeingUsed,Form2).Prop=123
end if

When this was already told, than sorry

I hope this helps anyway something?

Cor

 

[Just Me]

I already received good answers.
Thanks anyway!