Yes, your technique for removing all references to the form is fine, and
yes calling GC.Collect may or may not have an impact on behavior. However,
it is not garaunteed that it will, so relying on calling GC.Collect to fix
a timing issue is not a good solution.
David Wrighton
NET Compact Framework
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Paul [Paradise Solutions]" <Paul@Don'tChuffingSpamMe.com>
| Newsgroups: microsoft.public.dotnet.framework.compactframework
| Subject: Re: EnabledChanged event fires for InputPanel after form is
DISPOSED
| Date: Wed, 10 Dec 2003 11:05:02 +0000
| Lines: 193
| Message-ID: <
[email protected]>
| References: <
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
| NNTP-Posting-Host: 80.177.200.10
| Mime-Version: 1.0
| Content-Type: text/plain; charset=us-ascii; format=flowed
| Content-Transfer-Encoding: 7bit
| X-Trace: news.demon.co.uk 1071054312 23375 80.177.200.10 (10 Dec 2003
11:05:12 GMT)
| X-Complaints-To: (e-mail address removed)
| NNTP-Posting-Date: Wed, 10 Dec 2003 11:05:12 +0000 (UTC)
| In-Reply-To: <
[email protected]>
| X-Accept-Language: en-us, en
| User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b)
Gecko/20030901 Thunderbird/0.2
| Path:
cpmsftngxa07.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.su
l.t-online.de!t-online.de!kibo.news.demon.net!news.demon.co.uk!demon!not-for
-mail
| Xref: cpmsftngxa07.phx.gbl
microsoft.public.dotnet.framework.compactframework:40483
| X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
|
| OK...
|
| So given my code at the bottom, having one reference to the form object
| and setting that to nothing after a dispose, is this enough to remove
| all references?
|
| Also, would forcing a GC.Collect() have any impact on the behaviour?
|
| Thanks
|
|
| Paul
|
|
| David Wrighton [MS] wrote:
|
| > The InputPanel has been designed to present a different interface than
the
| > behavior that you expect. All InputPanel objects that are in existence
will
| > fire their events when the InputPanel is enabled or disabled.
InputPanels
| > will remain in existence until they are finalized by the garbage
collector.
| > The result of this behavior is that event handlers for the
| > InputPanel.Enabled event need to handle being called even after forms
have
| > been disposed. Disposing a form means that the native resources
associated
| > with the form have been freed, and if all references to the Form are
now
| > removed, then the form object can be fully cleaned up by the garbage
| > collector.
| >
| > David Wrighton
| > NET Compact Framework
| >
| > This posting is provided "AS IS" with no warranties, and confers no
rights.
| > --------------------
| > | From: "Paul [Paradise Solutions]" <Paul@Don'tChuffingSpamMe.com>
| > | Newsgroups: microsoft.public.dotnet.framework.compactframework
| > | Subject: Re: EnabledChanged event fires for InputPanel after form is
| > DISPOSED
| > | Date: Thu, 04 Dec 2003 09:18:05 +0000
| > | Lines: 119
| > | Message-ID: <
[email protected]>
| > | References: <
[email protected]>
| > <
[email protected]>
| > | NNTP-Posting-Host: 80.177.200.10
| > | Mime-Version: 1.0
| > | Content-Type: text/plain; charset=us-ascii; format=flowed
| > | Content-Transfer-Encoding: 7bit
| > | X-Trace: news.demon.co.uk 1070529485 14345 80.177.200.10 (4 Dec 2003
| > 09:18:05 GMT)
| > | X-Complaints-To: (e-mail address removed)
| > | NNTP-Posting-Date: Thu, 4 Dec 2003 09:18:05 +0000 (UTC)
| > | In-Reply-To: <
[email protected]>
| > | X-Accept-Language: en-us, en
| > | User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b)
| > Gecko/20030901 Thunderbird/0.2
| > | Path:
| >
cpmsftngxa07.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.su
| >
l.t-online.de!t-online.de!kibo.news.demon.net!news.demon.co.uk!demon!not-for
| > -mail
| > | Xref: cpmsftngxa07.phx.gbl
| > microsoft.public.dotnet.framework.compactframework:39997
| > | X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
| > |
| > | Graham
| > |
| > | I did see one posting to the original question about form being
closed -
| > | they said that as the Inputpanel is singleton (not ~entirely~ sure
what
| > | implications this has), all references to the 'unwanted form' must be
| > | removed. Though I'm unsure, then, what Dispose() actually does...
| > |
| > | It should also be noted (hence why my code is this way) that you
don't
| > | actually need to open the form in the first place - modal or
otherwise.
| > | As long as you at least instantiate the 'other' form, the
Inputpanel
| > | event will fire. It also seems to take prference to the second form
in
| > | my code for event sequence - I added a similar line of code in the
first
| > | forms event handler and the form2 event fired first every time.
| > |
| > | I'm not sure if SP2 will address this as no mention of this problem
| > | appeared in their 'locked down' bug fix-list...
| > |
| > |
| > | Paul
| > |
| > | Graham McKechnie wrote:
| > |
| > | > Paul,
| > | >
| > | > I've seen that behaviour in C# too. Happened to me when forcing a
close
| > | > after saving a record with this.Close(). After the form was closed
I
| > then
| > | > tapped on a search textBox on the window that was there before the
other
| > | > window was opened and it tried to execute code of the
| > | > inputpanel_EnabledChanged of the form that was already closed,
where as
| > it
| > | > should have been executing the inputpanel_EnabledChanged of the
window
| > with
| > | > the textbox. Your behaviour appears very similiar even in VB.
| > | >
| > | > I was able to work around the issue, by making the save record a
menu
| > | > choice, rather than being automatic. Now the user has to tap the OK
| > button
| > | > to close the window and the problem goes away. I got an
| > | > ObjectDisposedException when I had it the other way. I'd prefer to
have
| > the
| > | > automatic save record, close window senario, so I've left a huge
slab of
| > | > comments in that bit of code, for testing when SP2 is released.
| > | >
| > | > Its as though the run time gets mixed up with two events of the
same
| > name in
| > | > different classes.
| > | >
| > | > A somewhat similiar problem came up a couple of days ago with the
same
| > | > textbox. If the user tapped that textbox and then clicked the ok
| > button to
| > | > close the window to go back to the main window, I got another
| > exception. I
| > | > got around that one, by adding the following
| > | >
| > | > private void ClientsForm_Closing(object sender,
| > | > System.ComponentModel.CancelEventArgs e)
| > | > {
| > | > if ( inputPanel1.Enabled )
| > | > inputPanel1.Enabled = false;
| > | > }
| > | >
| > | > It appears the inputPanel is a bit touchy, and you should always
test
| > for
| > | > enabled before forcing an event to make it go one way or the other.
| > | >
| > | > I wish someone from MS would comment on this.
| > | >
| > | > Regards
| > | > Graham
| > | >
| > | >
| > message
| > | > | > | >
| > | >>This is similar to a previous posting, which concerned this
behaviour
| > | >>after closing a form.
| > | >>
| > | >>Create new project with 2 new forms, both with access to the
Inputpanel.
| > | >>
| > | >>Place the following code inside form1:
| > | >>
| > | >>'// class level
| > | >>private p_Form2 as Form2
| > | >>
| > | >>
| > | >> Private Sub Form1_Load(ByVal sender As System.Object, ByVal e
As
| > | >>System.EventArgs) Handles MyBase.Load
| > | >> p_form2 = New Form2
| > | >> p_form2.Dispose()
| > | >> p_form2 = Nothing
| > | >>Application.DoEvents()
| > | >> End Sub
| > | >>
| > | >> Private Sub Button1_Click(ByVal sender As System.Object, ByVal
e As
| > | >>System.EventArgs) Handles Button1.Click
| > | >> InputPanel1.Enabled = True
| > | >> End Sub
| > | >>
| > | >> Private Sub Form1_Closing(ByVal sender As Object, ByVal e As
| > | >>System.ComponentModel.CancelEventArgs) Handles MyBase.Closing
| > | >> End Sub
| > | >>
| > | >>
| > | >>Place the following code inside form2:
| > | >>
| > | >> Private Sub InputPanel1_EnabledChanged(ByVal sender As Object,
ByVal e
| > | >>As System.EventArgs) Handles InputPanel1.EnabledChanged
| > | >> MessageBox.Show("form2 handler firing")
| > | >> End Sub
| > | >>
| > | >>
| > | >>
| > | >>Why is it, even after disposing the form and the fact that the form
was
| > | >>never opened in the first place, does the event in form2 fire when
the
| > | >>button in form1 is tapped?
| > | >>Also, how can I get round this 'issue'?
| > | >>
| > | >>
| > | >>Many thanks
| > | >>
| > | >>
| > | >>Paul
| > | >>
| > | >
| > | >
| > | >
| > |
| > |
| >
|
|
