What replaces frmMain.ActiveForm (WinForms)

[Elmo Watson]

Let's say I have a child form - frmEdit - on that form a RichText Box called
txtedit

So - in VB6 days - I used to be able to refer to that particular active
form's Rich Text box - like this:

With frmMain.ActiveForm.txtedit.......

So - now - I'm using DotNet 2.0 - --

How can I do the same thing?

 

[Armin Zingler]

Let's say I have a child form - frmEdit - on that form a RichText
Box called txtedit

So - in VB6 days - I used to be able to refer to that particular
active form's Rich Text box - like this:

With frmMain.ActiveForm.txtedit.......

So - now - I'm using DotNet 2.0 - --

How can I do the same thing?

Reading your other question, I assume it's an MDI application.

The way you do it now was already bad practice in VB6 because not every
active Form must have a control named "txtEdit". They might have but not by
definition, as ActiveForm is of type Object and not each object has a
property txtEdit. I recommend early binding to get safer code. The solution
depends on how abstract the child form is to be. It also depends on whether
the MDI parent can contain different types of Forms or only instances of the
same Form. If the latter is the case, you can simply use
"Directcast(me.mdiparent.activemdichild, TypeOfChildForm).txtEdit". Before,
you probably will have to check that the active Form is not the Form that
does the check (because it probably does not have a txtEdit property). If
the former ist the case, you should consider deriving these Forms from the
same base form or implement an interface. Then cast to that interface or
base type to access txtEdit. You also would have to check whether the active
Form is of that type (If Typeof..is..).

In a good solution, many things must be considered to find a good design.


Armin

 

[Elmo Watson]

Well in this case, Every ActiveForm WILL contain a txtEdit -
That just seems like a lot of code just to access the txtEdit control on the
active form.
I'm using DotNet 2.0, by the way - I thought DotNet was all about
(especially with 2.0) reducing coding

 

[Elmo Watson]

I tried that - in VS.net 2005, I get a 'TypeofChildForm' is not defined.....
Then, in the Red correction Dot - there's no available correction
available....

 

[Armin Zingler]

I tried that - in VS.net 2005, I get a 'TypeofChildForm' is not
defined..... Then, in the Red correction Dot - there's no available
correction available....

Replace 'TypeofChildForm' by the type of the child Form. Example: If
it's class name is 'MyMdiChild', use
Directcast(me.mdiparent.activemdichild, myMdiChild).txtEdit


Armin

 

[Armin Zingler]

Well in this case, Every ActiveForm WILL contain a txtEdit -

Do you mean every instance or every class? This means, do you have several
instances of the same Form class or do you have several Form classes, all
having a txtEdit property/field?

That just seems like a lot of code just to access the txtEdit
control on the active form.

a) The type of ActiveForm is Form.
b) The Form class does not have a txtEdit property
Thus you will have to cast to the specific type. Using an interface or a
common base class makes it easier because you only have to cast to that
type. Otherwise you'd have to check several types (if you do have several
types as asked above).

I'm using DotNet 2.0, by the way - I thought DotNet was all about
(especially with 2.0) reducing coding

Programming is all about type safety. Safety first. Enabling late binding
(as you did in VB6) can make programming quicker, but it's more dangerous.
It's more dangerous because it disables some compile time checks and
consequently creates the risk of undiscovered programming errors that cost
you more time in the end than you thought you saved before. It can, it
doesn't have to. Using late binding or not is a matter of how much risk
you want to take. I, personally, don't want to answer for faults caused
by turned-off compile time checks. I will always use this free and helpful
offer.


Armin