-
Detecting change of MDI child form
Can anyone please advise which (if any) message is received by an MDIForm
when it's active child form changes?
Alternatively, is there a simpler method (not using the API) to detect change
of active child form?
Thanks for your help.
Tim Coulter
-
Re: Detecting change of MDI child form
WM_MDIACTIVATE is sent to the MDIClient window. (The MDIClient window
is a child of the MDIForm and is the area in which the child forms are
displayed.) It's up to the MDIClient to activate the appropriate child
and send WM_MDIACTIVATE to both the child being activated and the
child being de-activated. However since VB maps these to the child
form Activate and Deactivate events, there's typically no need to deal
with the message stream directly
On 29 Jan 2001 08:13:53 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
wrote:
>Can anyone please advise which (if any) message is received by an MDIForm
>when it's active child form changes?
>
>Alternatively, is there a simpler method (not using the API) to detect change
>of active child form?
>
>Thanks for your help.
>Tim Coulter
-Tom
(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
WM_MDIACTIVATE is sent to the MDIClient window. (The MDIClient window
is a child of the MDIForm and is the area in which the child forms are
displayed.) It's up to the MDIClient to activate the appropriate child
and send WM_MDIACTIVATE to both the child being activated and the
child being de-activated. However since VB maps these to the child
form Activate and Deactivate events, there's typically no need to deal
with the message stream directly
On 29 Jan 2001 08:13:53 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
wrote:
>Can anyone please advise which (if any) message is received by an MDIForm
>when it's active child form changes?
>
>Alternatively, is there a simpler method (not using the API) to detect change
>of active child form?
>
>Thanks for your help.
>Tim Coulter
-Tom
(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Tom,
Many thanks for your response to my question. I am a little closer to achieving
my objective, but not quite there yet.
What I really want to do is raise events within child forms which can be
handled in the MDI parent form. To do this, the MDIForm needs to keep track
of the active child form, and so it needs an event (or equivalent) which
indicates when the user switches between child forms.
From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
message to the MDIClient window. But can you please tell me how to get a
hWnd for the MDIClient window?
Thanks again for your advice.
Tim Coulter
tjeshGibberish@blazenet.net (Tom Esh) wrote:
>WM_MDIACTIVATE is sent to the MDIClient window. (The MDIClient window
>is a child of the MDIForm and is the area in which the child forms are
>displayed.) It's up to the MDIClient to activate the appropriate child
>and send WM_MDIACTIVATE to both the child being activated and the
>child being de-activated. However since VB maps these to the child
>form Activate and Deactivate events, there's typically no need to deal
>with the message stream directly
>
>On 29 Jan 2001 08:13:53 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
>wrote:
>>Can anyone please advise which (if any) message is received by an MDIForm
>>when it's active child form changes?
>>
>>Alternatively, is there a simpler method (not using the API) to detect
change
>>of active child form?
>>
>>Thanks for your help.
>>Tim Coulter
>
>
>-Tom
>(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Tom,
Many thanks for your response to my question. I am a little closer to achieving
my objective, but not quite there yet.
What I really want to do is raise events within child forms which can be
handled in the MDI parent form. To do this, the MDIForm needs to keep track
of the active child form, and so it needs an event (or equivalent) which
indicates when the user switches between child forms.
From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
message to the MDIClient window. But can you please tell me how to get a
hWnd for the MDIClient window?
Thanks again for your advice.
Tim Coulter
tjeshGibberish@blazenet.net (Tom Esh) wrote:
>WM_MDIACTIVATE is sent to the MDIClient window. (The MDIClient window
>is a child of the MDIForm and is the area in which the child forms are
>displayed.) It's up to the MDIClient to activate the appropriate child
>and send WM_MDIACTIVATE to both the child being activated and the
>child being de-activated. However since VB maps these to the child
>form Activate and Deactivate events, there's typically no need to deal
>with the message stream directly
>
>On 29 Jan 2001 08:13:53 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
>wrote:
>>Can anyone please advise which (if any) message is received by an MDIForm
>>when it's active child form changes?
>>
>>Alternatively, is there a simpler method (not using the API) to detect
change
>>of active child form?
>>
>>Thanks for your help.
>>Tim Coulter
>
>
>-Tom
>(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
news:3a75de9c$1@news.devx.com...
>
> What I really want to do is raise events within child forms which can be
Sinking events for MDI children may prove to be very limited in use. The
problem lies in VB not allowing WithEvents to be used with arrays. So you
will only be able Sink an Event of the activating form if you limit the
number of mdi children to that allow loaded. You'll need one variable for
each form. Then each event would have to be coded separately. This can get
very messy.
Since VB only allows 1 MDI form per application, why not just code public
subs inplace of event sinks?
> From your explanation, I now understand that I need to intercept the
WM_MDIACTIVATE
> message to the MDIClient window. But can you please tell me how to get a
Well, you could put the code into form_Activate event for the mdi child
forms as the last line in Tom's post indicates. This should be clean enough
unless you have different form types to be shown as mdi children.
Here's an example:
'MDI form code
Option Explicit
Public Sub Activated()
Me.Caption = "MDI form: Child " & ActiveForm.Caption
End Sub
Private Sub mnuNew_Click()
With New frmChild
.Caption = Forms.Count
.Show
End With
End Sub
'mdi child form code
Private Sub Form_Activate()
MDIForm1.Activated
End Sub
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
-
Re: Detecting change of MDI child form
Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
news:3a75de9c$1@news.devx.com...
>
> What I really want to do is raise events within child forms which can be
Sinking events for MDI children may prove to be very limited in use. The
problem lies in VB not allowing WithEvents to be used with arrays. So you
will only be able Sink an Event of the activating form if you limit the
number of mdi children to that allow loaded. You'll need one variable for
each form. Then each event would have to be coded separately. This can get
very messy.
Since VB only allows 1 MDI form per application, why not just code public
subs inplace of event sinks?
> From your explanation, I now understand that I need to intercept the
WM_MDIACTIVATE
> message to the MDIClient window. But can you please tell me how to get a
Well, you could put the code into form_Activate event for the mdi child
forms as the last line in Tom's post indicates. This should be clean enough
unless you have different form types to be shown as mdi children.
Here's an example:
'MDI form code
Option Explicit
Public Sub Activated()
Me.Caption = "MDI form: Child " & ActiveForm.Caption
End Sub
Private Sub mnuNew_Click()
With New frmChild
.Caption = Forms.Count
.Show
End With
End Sub
'mdi child form code
Private Sub Form_Activate()
MDIForm1.Activated
End Sub
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
-
Re: Detecting change of MDI child form
mr felis,
you only need to get the events of 1 form - the active one. When you get a
form_deactive event just change the variable to be the new form. There would
be some additional stuffing around when no forms were visible but it most
likely would be workable.
We use a different method. We have a usercontrol on the MDI form (we call it
the AM control) and a control on every MDI child form (called the FM
control - inhouse joke). When the FM control detects that the form loses
focus it sends a message to the AM control which raises an event on the MDI
form. It also serves other purposes such as toolbar control, sending
messages between forms etc.
>The problem lies in VB not allowing WithEvents to be used with arrays
There are ways around this. Which boils down to creating an array of classes
that has a withevents variable in it and then having the classes call a
central location.
Michael Culley
"mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
news:3a7600ac$1@news.devx.com...
> Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
> news:3a75de9c$1@news.devx.com...
> >
> > What I really want to do is raise events within child forms which can be
> Sinking events for MDI children may prove to be very limited in use. The
> problem lies in VB not allowing WithEvents to be used with arrays. So you
> will only be able Sink an Event of the activating form if you limit the
> number of mdi children to that allow loaded. You'll need one variable for
> each form. Then each event would have to be coded separately. This can get
> very messy.
>
> Since VB only allows 1 MDI form per application, why not just code public
> subs inplace of event sinks?
>
> > From your explanation, I now understand that I need to intercept the
> WM_MDIACTIVATE
> > message to the MDIClient window. But can you please tell me how to get a
>
> Well, you could put the code into form_Activate event for the mdi child
> forms as the last line in Tom's post indicates. This should be clean
enough
> unless you have different form types to be shown as mdi children.
>
> Here's an example:
>
> 'MDI form code
> Option Explicit
>
> Public Sub Activated()
> Me.Caption = "MDI form: Child " & ActiveForm.Caption
> End Sub
>
>
> Private Sub mnuNew_Click()
> With New frmChild
> .Caption = Forms.Count
> .Show
> End With
> End Sub
>
> 'mdi child form code
> Private Sub Form_Activate()
> MDIForm1.Activated
> End Sub
>
>
>
> --
> ~~~
> !ti timda I ,KO
> .em deppals nocaeB sivaM
> !draH
> ~~
> C'Ya,
> mrfelis@yahoo!com
>
>
>
-
Re: Detecting change of MDI child form
mr felis,
you only need to get the events of 1 form - the active one. When you get a
form_deactive event just change the variable to be the new form. There would
be some additional stuffing around when no forms were visible but it most
likely would be workable.
We use a different method. We have a usercontrol on the MDI form (we call it
the AM control) and a control on every MDI child form (called the FM
control - inhouse joke). When the FM control detects that the form loses
focus it sends a message to the AM control which raises an event on the MDI
form. It also serves other purposes such as toolbar control, sending
messages between forms etc.
>The problem lies in VB not allowing WithEvents to be used with arrays
There are ways around this. Which boils down to creating an array of classes
that has a withevents variable in it and then having the classes call a
central location.
Michael Culley
"mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
news:3a7600ac$1@news.devx.com...
> Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
> news:3a75de9c$1@news.devx.com...
> >
> > What I really want to do is raise events within child forms which can be
> Sinking events for MDI children may prove to be very limited in use. The
> problem lies in VB not allowing WithEvents to be used with arrays. So you
> will only be able Sink an Event of the activating form if you limit the
> number of mdi children to that allow loaded. You'll need one variable for
> each form. Then each event would have to be coded separately. This can get
> very messy.
>
> Since VB only allows 1 MDI form per application, why not just code public
> subs inplace of event sinks?
>
> > From your explanation, I now understand that I need to intercept the
> WM_MDIACTIVATE
> > message to the MDIClient window. But can you please tell me how to get a
>
> Well, you could put the code into form_Activate event for the mdi child
> forms as the last line in Tom's post indicates. This should be clean
enough
> unless you have different form types to be shown as mdi children.
>
> Here's an example:
>
> 'MDI form code
> Option Explicit
>
> Public Sub Activated()
> Me.Caption = "MDI form: Child " & ActiveForm.Caption
> End Sub
>
>
> Private Sub mnuNew_Click()
> With New frmChild
> .Caption = Forms.Count
> .Show
> End With
> End Sub
>
> 'mdi child form code
> Private Sub Form_Activate()
> MDIForm1.Activated
> End Sub
>
>
>
> --
> ~~~
> !ti timda I ,KO
> .em deppals nocaeB sivaM
> !draH
> ~~
> C'Ya,
> mrfelis@yahoo!com
>
>
>
-
Re: Detecting change of MDI child form
>...But can you please tell me how to get a
>hWnd for the MDIClient window?..
The classname is "MDIClient", so...
hwndClient = FindWindowEx(MDIForm.hwnd, 0&, "MDIClient", vbNullString)
....does it.
Note however the specific child being activated/deactivated is not
identified in the msg params received by MDIClient. (Windows just
tosses the message at MDIClient and expects it to figure out the
rest.) I'm not sure about the sequence, but the MDIForm.ActiveForm
prop may not get updated until WM_MDIACTIVATE has been processed.
Truth is I've never needed the Api for this. Typically I just have the
child call a public or friend method in the MDI parent form, and if
neccessary pass a reference to itself.
Ex:
'In the MDI parent...
Friend Sub ChildActivated(oChild As frmChild)
'...do whatever...
End Sub
'In frmChild...
Private Sub Form_Activate()
MDIForm.ChildActivated Me
End Sub
On 29 Jan 2001 13:20:28 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
wrote:
>
>Tom,
>
>Many thanks for your response to my question. I am a little closer to achieving
>my objective, but not quite there yet.
>
>What I really want to do is raise events within child forms which can be
>handled in the MDI parent form. To do this, the MDIForm needs to keep track
>of the active child form, and so it needs an event (or equivalent) which
>indicates when the user switches between child forms.
>
>From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
>message to the MDIClient window. But can you please tell me how to get a
>hWnd for the MDIClient window?
>
>Thanks again for your advice.
>Tim Coulter
>
-Tom
(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
>...But can you please tell me how to get a
>hWnd for the MDIClient window?..
The classname is "MDIClient", so...
hwndClient = FindWindowEx(MDIForm.hwnd, 0&, "MDIClient", vbNullString)
....does it.
Note however the specific child being activated/deactivated is not
identified in the msg params received by MDIClient. (Windows just
tosses the message at MDIClient and expects it to figure out the
rest.) I'm not sure about the sequence, but the MDIForm.ActiveForm
prop may not get updated until WM_MDIACTIVATE has been processed.
Truth is I've never needed the Api for this. Typically I just have the
child call a public or friend method in the MDI parent form, and if
neccessary pass a reference to itself.
Ex:
'In the MDI parent...
Friend Sub ChildActivated(oChild As frmChild)
'...do whatever...
End Sub
'In frmChild...
Private Sub Form_Activate()
MDIForm.ChildActivated Me
End Sub
On 29 Jan 2001 13:20:28 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
wrote:
>
>Tom,
>
>Many thanks for your response to my question. I am a little closer to achieving
>my objective, but not quite there yet.
>
>What I really want to do is raise events within child forms which can be
>handled in the MDI parent form. To do this, the MDIForm needs to keep track
>of the active child form, and so it needs an event (or equivalent) which
>indicates when the user switches between child forms.
>
>From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
>message to the MDIClient window. But can you please tell me how to get a
>hWnd for the MDIClient window?
>
>Thanks again for your advice.
>Tim Coulter
>
-Tom
(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Thanks to everyone for your suggestions. As Michael pointed out, it is only
necessary to sink the events for the active child form (hence the need to
know when it changes) so it would be reasonable to get the each child form
to notify the MDIForm when it becomes active. However, from my experimentation,
the biggest problem occurs when the last child form is closed, since the
MDIForm has no way of knowing that the active form is Nothing.
Tom, you were right, the WM_MDIACTIVATE message occurs before the MDIForm.ActiveForm
property changes, so this is not going to help.
Michael, your AM/FM concept sounds like a very sound approach. Is it possible
to get some details of the workings, or is it confidential?
Thanks again everone.
Tim Coulter
tjeshGibberish@blazenet.net (Tom Esh) wrote:
>>...But can you please tell me how to get a
>>hWnd for the MDIClient window?..
>The classname is "MDIClient", so...
>hwndClient = FindWindowEx(MDIForm.hwnd, 0&, "MDIClient", vbNullString)
>....does it.
>Note however the specific child being activated/deactivated is not
>identified in the msg params received by MDIClient. (Windows just
>tosses the message at MDIClient and expects it to figure out the
>rest.) I'm not sure about the sequence, but the MDIForm.ActiveForm
>prop may not get updated until WM_MDIACTIVATE has been processed.
>
>Truth is I've never needed the Api for this. Typically I just have the
>child call a public or friend method in the MDI parent form, and if
>neccessary pass a reference to itself.
>
>Ex:
>'In the MDI parent...
>Friend Sub ChildActivated(oChild As frmChild)
> '...do whatever...
>End Sub
>
>'In frmChild...
>Private Sub Form_Activate()
> MDIForm.ChildActivated Me
>End Sub
>
>
>On 29 Jan 2001 13:20:28 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
>wrote:
>
>>
>>Tom,
>>
>>Many thanks for your response to my question. I am a little closer to achieving
>>my objective, but not quite there yet.
>>
>>What I really want to do is raise events within child forms which can be
>>handled in the MDI parent form. To do this, the MDIForm needs to keep track
>>of the active child form, and so it needs an event (or equivalent) which
>>indicates when the user switches between child forms.
>>
>>From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
>>message to the MDIClient window. But can you please tell me how to get
a
>>hWnd for the MDIClient window?
>>
>>Thanks again for your advice.
>>Tim Coulter
>>
>
>
>-Tom
>(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Thanks to everyone for your suggestions. As Michael pointed out, it is only
necessary to sink the events for the active child form (hence the need to
know when it changes) so it would be reasonable to get the each child form
to notify the MDIForm when it becomes active. However, from my experimentation,
the biggest problem occurs when the last child form is closed, since the
MDIForm has no way of knowing that the active form is Nothing.
Tom, you were right, the WM_MDIACTIVATE message occurs before the MDIForm.ActiveForm
property changes, so this is not going to help.
Michael, your AM/FM concept sounds like a very sound approach. Is it possible
to get some details of the workings, or is it confidential?
Thanks again everone.
Tim Coulter
tjeshGibberish@blazenet.net (Tom Esh) wrote:
>>...But can you please tell me how to get a
>>hWnd for the MDIClient window?..
>The classname is "MDIClient", so...
>hwndClient = FindWindowEx(MDIForm.hwnd, 0&, "MDIClient", vbNullString)
>....does it.
>Note however the specific child being activated/deactivated is not
>identified in the msg params received by MDIClient. (Windows just
>tosses the message at MDIClient and expects it to figure out the
>rest.) I'm not sure about the sequence, but the MDIForm.ActiveForm
>prop may not get updated until WM_MDIACTIVATE has been processed.
>
>Truth is I've never needed the Api for this. Typically I just have the
>child call a public or friend method in the MDI parent form, and if
>neccessary pass a reference to itself.
>
>Ex:
>'In the MDI parent...
>Friend Sub ChildActivated(oChild As frmChild)
> '...do whatever...
>End Sub
>
>'In frmChild...
>Private Sub Form_Activate()
> MDIForm.ChildActivated Me
>End Sub
>
>
>On 29 Jan 2001 13:20:28 -0800, "Tim Coulter" <tim.coulter@wanadoo.fr>
>wrote:
>
>>
>>Tom,
>>
>>Many thanks for your response to my question. I am a little closer to achieving
>>my objective, but not quite there yet.
>>
>>What I really want to do is raise events within child forms which can be
>>handled in the MDI parent form. To do this, the MDIForm needs to keep track
>>of the active child form, and so it needs an event (or equivalent) which
>>indicates when the user switches between child forms.
>>
>>From your explanation, I now understand that I need to intercept the WM_MDIACTIVATE
>>message to the MDIClient window. But can you please tell me how to get
a
>>hWnd for the MDIClient window?
>>
>>Thanks again for your advice.
>>Tim Coulter
>>
>
>
>-Tom
>(please post replies to the newsgroup)
-
Re: Detecting change of MDI child form
Michael Culley <mike@vbdotcom.com> wrote in message
news:3a76137c@news.devx.com...
> mr felis,
>
> you only need to get the events of 1 form - the active one. When you get a
> form_deactive event just change the variable to be the new form. There
would
Does the MDIForm.ActiveForm property get changed before or after the child
form_deactivate? If it is after, who would you catch the event for the
activating form using the single variable?
The object array inside a collection raising evnets could work though.
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
Michael Culley <mike@vbdotcom.com> wrote in message
news:3a76137c@news.devx.com...
> mr felis,
>
> you only need to get the events of 1 form - the active one. When you get a
> form_deactive event just change the variable to be the new form. There
would
> be some additional stuffing around when no forms were visible but it most
> likely would be workable.
>
> We use a different method. We have a usercontrol on the MDI form (we call
it
> the AM control) and a control on every MDI child form (called the FM
> control - inhouse joke). When the FM control detects that the form loses
> focus it sends a message to the AM control which raises an event on the
MDI
> form. It also serves other purposes such as toolbar control, sending
> messages between forms etc.
>
> >The problem lies in VB not allowing WithEvents to be used with arrays
>
> There are ways around this. Which boils down to creating an array of
classes
> that has a withevents variable in it and then having the classes call a
> central location.
>
> Michael Culley
>
> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
> news:3a7600ac$1@news.devx.com...
> > Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
> > news:3a75de9c$1@news.devx.com...
> > >
> > > What I really want to do is raise events within child forms which can
be
> > Sinking events for MDI children may prove to be very limited in use. The
> > problem lies in VB not allowing WithEvents to be used with arrays. So
you
> > will only be able Sink an Event of the activating form if you limit the
> > number of mdi children to that allow loaded. You'll need one variable
for
> > each form. Then each event would have to be coded separately. This can
get
> > very messy.
> >
> > Since VB only allows 1 MDI form per application, why not just code
public
> > subs inplace of event sinks?
> >
> > > From your explanation, I now understand that I need to intercept the
> > WM_MDIACTIVATE
> > > message to the MDIClient window. But can you please tell me how to get
a
> >
> > Well, you could put the code into form_Activate event for the mdi child
> > forms as the last line in Tom's post indicates. This should be clean
> enough
> > unless you have different form types to be shown as mdi children.
> >
> > Here's an example:
> >
> > 'MDI form code
> > Option Explicit
> >
> > Public Sub Activated()
> > Me.Caption = "MDI form: Child " & ActiveForm.Caption
> > End Sub
> >
> >
> > Private Sub mnuNew_Click()
> > With New frmChild
> > .Caption = Forms.Count
> > .Show
> > End With
> > End Sub
> >
> > 'mdi child form code
> > Private Sub Form_Activate()
> > MDIForm1.Activated
> > End Sub
> >
> >
> >
> > --
> > ~~~
> > !ti timda I ,KO
> > .em deppals nocaeB sivaM
> > !draH
> > ~~
> > C'Ya,
> > mrfelis@yahoo!com
> >
> >
> >
>
>
-
Re: Detecting change of MDI child form
Michael Culley <mike@vbdotcom.com> wrote in message
news:3a76137c@news.devx.com...
> mr felis,
>
> you only need to get the events of 1 form - the active one. When you get a
> form_deactive event just change the variable to be the new form. There
would
Does the MDIForm.ActiveForm property get changed before or after the child
form_deactivate? If it is after, who would you catch the event for the
activating form using the single variable?
The object array inside a collection raising evnets could work though.
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
Michael Culley <mike@vbdotcom.com> wrote in message
news:3a76137c@news.devx.com...
> mr felis,
>
> you only need to get the events of 1 form - the active one. When you get a
> form_deactive event just change the variable to be the new form. There
would
> be some additional stuffing around when no forms were visible but it most
> likely would be workable.
>
> We use a different method. We have a usercontrol on the MDI form (we call
it
> the AM control) and a control on every MDI child form (called the FM
> control - inhouse joke). When the FM control detects that the form loses
> focus it sends a message to the AM control which raises an event on the
MDI
> form. It also serves other purposes such as toolbar control, sending
> messages between forms etc.
>
> >The problem lies in VB not allowing WithEvents to be used with arrays
>
> There are ways around this. Which boils down to creating an array of
classes
> that has a withevents variable in it and then having the classes call a
> central location.
>
> Michael Culley
>
> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
> news:3a7600ac$1@news.devx.com...
> > Tim Coulter <tim.coulter@wanadoo.fr> wrote in message
> > news:3a75de9c$1@news.devx.com...
> > >
> > > What I really want to do is raise events within child forms which can
be
> > Sinking events for MDI children may prove to be very limited in use. The
> > problem lies in VB not allowing WithEvents to be used with arrays. So
you
> > will only be able Sink an Event of the activating form if you limit the
> > number of mdi children to that allow loaded. You'll need one variable
for
> > each form. Then each event would have to be coded separately. This can
get
> > very messy.
> >
> > Since VB only allows 1 MDI form per application, why not just code
public
> > subs inplace of event sinks?
> >
> > > From your explanation, I now understand that I need to intercept the
> > WM_MDIACTIVATE
> > > message to the MDIClient window. But can you please tell me how to get
a
> >
> > Well, you could put the code into form_Activate event for the mdi child
> > forms as the last line in Tom's post indicates. This should be clean
> enough
> > unless you have different form types to be shown as mdi children.
> >
> > Here's an example:
> >
> > 'MDI form code
> > Option Explicit
> >
> > Public Sub Activated()
> > Me.Caption = "MDI form: Child " & ActiveForm.Caption
> > End Sub
> >
> >
> > Private Sub mnuNew_Click()
> > With New frmChild
> > .Caption = Forms.Count
> > .Show
> > End With
> > End Sub
> >
> > 'mdi child form code
> > Private Sub Form_Activate()
> > MDIForm1.Activated
> > End Sub
> >
> >
> >
> > --
> > ~~~
> > !ti timda I ,KO
> > .em deppals nocaeB sivaM
> > !draH
> > ~~
> > C'Ya,
> > mrfelis@yahoo!com
> >
> >
> >
>
>
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Development Centers
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center
|