By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,600 Members | 1,666 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,600 IT Pros & Developers. It's quick & easy.

What replaces frmMain.ActiveForm (WinForms)

P: n/a
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?
Nov 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Elmo Watson" <sp*****@nospam.yahoo.com> schrieb
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

Nov 23 '05 #2

P: n/a
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
:)

"Armin Zingler" <az*******@freenet.de> wrote in message
news:Os**************@TK2MSFTNGP12.phx.gbl...
"Elmo Watson" <sp*****@nospam.yahoo.com> schrieb
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

Nov 23 '05 #3

P: n/a
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" <az*******@freenet.de> wrote in message
news:Os**************@TK2MSFTNGP12.phx.gbl...
"Elmo Watson" <sp*****@nospam.yahoo.com> schrieb
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

Nov 23 '05 #4

P: n/a
"Elmo Watson" <sp**********@NOSpam.yahoo.com> schrieb

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.

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

Nov 23 '05 #5

P: n/a
"Elmo Watson" <sp**********@NOSpam.yahoo.com> schrieb
"Armin Zingler" <az*******@freenet.de> wrote in message
news:Os**************@TK2MSFTNGP12.phx.gbl...
"Elmo Watson" <sp*****@nospam.yahoo.com> schrieb
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.


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

Nov 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.