showdialog and 'Cannot access a disposed object'

[chris Burgess]

I have the following code to launch forms based upon a selection from
a list box:

Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles LoadReport.Click
Dim rpt As New BaseReport
rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
rpt.ShowDialog()
rpt.Dispose()
End Sub

'Reports' is a list box that contains 'Report' objects. The Report
object has a report name property (the DisplayMember) and a report
form property, each of which is derived from BaseForm (the
.valuemember).

If I launch a report form, close it, then try to launch it again, I
get an error:

System.ObjectDisposedException was unhandled
Message="Cannot access a disposed object.
Object name: 'Report_OrdersByDate'."
ObjectName="Report_OrdersByDate"
Source="System.Windows.Forms"
StackTrace:
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m,
MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(ApplicationContext context)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[]
commandLine)
at Converse.My.MyApplication.Main(String[] Args) in
17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile,
Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

[Bhatnagar, Amit]

you disposed your dialog, how do you expect it to show up again? Create
a new one (via new) and then use it.

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
chris Burgess
Sent: Friday, January 04, 2008 8:28 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] showdialog and 'Cannot access a disposed
object'

I have the following code to launch forms based upon a selection from a
list box:

Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles LoadReport.Click
Dim rpt As New BaseReport
rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
rpt.ShowDialog()
rpt.Dispose()
End Sub

'Reports' is a list box that contains 'Report' objects. The Report
object has a report name property (the DisplayMember) and a report form
property, each of which is derived from BaseForm (the .valuemember).

If I launch a report form, close it, then try to launch it again, I get
an error:

System.ObjectDisposedException was unhandled
Message="Cannot access a disposed object.
Object name: 'Report_OrdersByDate'."
ObjectName="Report_OrdersByDate"
Source="System.Windows.Forms"
StackTrace:
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m,
MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at
System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at
System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.U
nsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(ApplicationContext
context)
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.On
Run()
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Do
ApplicationModel()
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Ru
n(String[]
commandLine)
at Converse.My.MyApplication.Main(String[] Args) in
17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence
assemblySecurity, String[] args)
at
Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object
state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Greg Robinson]

"rpt" has been disposed so it's no longer available.


Greg Robinson
Custom Data Systems, Inc.
www.cds-am.net

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM]On Behalf Of
chris Burgess
Sent: Friday, January 04, 2008 10:28 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] showdialog and 'Cannot access a disposed
object'


I have the following code to launch forms based upon a selection from
a list box:

Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles LoadReport.Click
Dim rpt As New BaseReport
rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
rpt.ShowDialog()
rpt.Dispose()
End Sub

'Reports' is a list box that contains 'Report' objects. The Report
object has a report name property (the DisplayMember) and a report
form property, each of which is derived from BaseForm (the
.valuemember).

If I launch a report form, close it, then try to launch it again, I
get an error:

System.ObjectDisposedException was unhandled
Message="Cannot access a disposed object.
Object name: 'Report_OrdersByDate'."
ObjectName="Report_OrdersByDate"
Source="System.Windows.Forms"
StackTrace:
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m,
MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at
System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.Unsaf
eNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(ApplicationContext context)
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun(
)
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoAppl
icationModel()
at
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(St
ring[]
commandLine)
at Converse.My.MyApplication.Main(String[] Args) in
17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
args)
at System.AppDomain.ExecuteAssembly(String assemblyFile,
Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

[Mike Andrews]

The issue is that you're creating a new Report via this line:

Dim rpt As New BaseReport

and then destroying it and in place of it setting an existing one:

rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)

since the list box contains the references to the report object, and you've
previously disposed it it will fail to run.
You need to refrain from calling the dispose() method until you're done with
the form in which the listbox resides.
You can then dispose all of the reports.
Also, change the first two lines of code to this:

Dim rpt As BaseReport = DirectCast(Me.Reports.SelectedValue, BaseReport)

or better still...

DirectCast(Me.Reports.SelectedValue, BaseReport).ShowDialog()

and leave off the dispose until it should be disposed.


On Jan 4, 2008 9:28 AM, chris Burgess <***@gmail.com> wrote:

> I have the following code to launch forms based upon a selection from
> a list box:
>
> Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e
> As System.EventArgs) Handles LoadReport.Click
> Dim rpt As New BaseReport
> rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> rpt.ShowDialog()
> rpt.Dispose()
> End Sub
>
> 'Reports' is a list box that contains 'Report' objects. The Report
> object has a report name property (the DisplayMember) and a report
> form property, each of which is derived from BaseForm (the
> .valuemember).
>
> If I launch a report form, close it, then try to launch it again, I
> get an error:
>
> System.ObjectDisposedException was unhandled
> Message="Cannot access a disposed object.
> Object name: 'Report_OrdersByDate'."
> ObjectName="Report_OrdersByDate"
> Source="System.Windows.Forms"
> StackTrace:
> at System.Windows.Forms.Control.CreateHandle()
> at System.Windows.Forms.Form.CreateHandle()
> at System.Windows.Forms.Control.get_Handle()
> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> at System.Windows.Forms.Form.ShowDialog()
> at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
> e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
> at System.Windows.Forms.Control.OnClick(EventArgs e)
> at System.Windows.Forms.Button.OnClick(EventArgs e)
> at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
> at System.Windows.Forms.Control.WmMouseUp(Message& m,
> MouseButtons button, Int32 clicks)
> at System.Windows.Forms.Control.WndProc(Message& m)
> at System.Windows.Forms.ButtonBase.WndProc(Message& m)
> at System.Windows.Forms.Button.WndProc(Message& m)
> at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> m)
> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
> m)
> at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
> hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
> msg)
> at
> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop
> (Int32
> dwComponentID, Int32 reason, Int32 pvLoopData)
> at
> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Application.ThreadContext.RunMessageLoop
> (Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Application.Run(ApplicationContext context)
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun
> ()
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel
> ()
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run
> (String[]
> commandLine)
> at Converse.My.MyApplication.Main(String[] Args) in
> 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
> at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
> args)
> at System.AppDomain.ExecuteAssembly(String assemblyFile,
> Evidence assemblySecurity, String[] args)
> at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
> at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
> at System.Threading.ExecutionContext.Run(ExecutionContext
> executionContext, ContextCallback callback, Object state)
> at System.Threading.ThreadHelper.ThreadStart()
>

[Peter Ritchie]

On Fri, 4 Jan 2008 09:56:41 -0600, Mike Andrews
<***@GMAIL.COM> wrote:

>The issue is that you're creating a new Report via this line:
>
>Dim rpt As New BaseReport
>
>and then destroying it and in place of it setting an existing one:
>
>rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
>
>since the list box contains the references to the report object, and
you've
>previously disposed it it will fail to run.
>You need to refrain from calling the dispose() method until you're done
with
>the form in which the listbox resides.
>You can then dispose all of the reports.

Bingo, the Reports object should be responsible for disposing what it
aggregates (or the owner of the Reports object if that class doesn't have
that concept).

[chris Burgess]

I think what I really want is to have the report object hold the type
of report form instead of a reference to the actual form object. I
want the button to create a new form each time of the type listed in
the list box/report object, and not reference existing objects.




On Jan 4, 2008 10:53 AM, Peter Ritchie
<***@peterritchie.com> wrote:
> On Fri, 4 Jan 2008 09:56:41 -0600, Mike Andrews
> <***@GMAIL.COM> wrote:
>
> >The issue is that you're creating a new Report via this line:
> >
> >Dim rpt As New BaseReport
> >
> >and then destroying it and in place of it setting an existing one:
> >
> >rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> >
> >since the list box contains the references to the report object, and
> you've
> >previously disposed it it will fail to run.
> >You need to refrain from calling the dispose() method until you're done
> with
> >the form in which the listbox resides.
> >You can then dispose all of the reports.
>
> Bingo, the Reports object should be responsible for disposing what it
> aggregates (or the owner of the Reports object if that class doesn't have
> that concept).
>

[Matthew Wills]

Chris,

This probably isn't the best way, but it should point you down the right
track. Note in particular that I am populating the hashtable with the type
rather than an instance of it. Then I am pulling out the type, getting its
constructor and calling it to create the type.

Again, there is probably a better way to do this - but I pulled this
together rather quickly.

Option Strict On

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Dim x As New Hashtable

Call x.Add("Bob", GetType(Class1))

Dim y As Type = CType(x.Item("Bob"), Type)

Dim z As System.Reflection.ConstructorInfo =
y.GetConstructor(System.Type.EmptyTypes)

Dim parameters As Object() = Nothing

Dim a As Class1 = CType(z.Invoke(parameters), Class1)

MsgBox(TypeName(a))

End Sub
End Class

Public Class Class1

End Class

Seeya
Matthew Wills | Solution Designer | Adviser Tools and Services | Financial
Planning and Third Party | NAB Technology

Phone: [phone] | Mobile: [phone] | Email:
***@nab.com.au




chris Burgess
<***@GMAI
L.COM> To
Sent by: DOTNET-***@DISCUSS.DEVELOP.COM
Discussion forum cc
for developers
using Windows Subject
Forms to build Re: [DOTNET-WINFORMS] showdialog
apps and 'Cannot access a disposed
and controls object'
<DOTNET-WINFORMS@
DISCUSS.DEVELOP.C
OM>


05/01/2008 03:49
AM


Please respond to
Discussion forum
for developers
using Windows
Forms to build
apps
and controls
<DOTNET-WINFORMS@
DISCUSS.DEVELOP.C
OM>






I think what I really want is to have the report object hold the type
of report form instead of a reference to the actual form object. I
want the button to create a new form each time of the type listed in
the list box/report object, and not reference existing objects.




On Jan 4, 2008 10:53 AM, Peter Ritchie
<***@peterritchie.com> wrote:
> On Fri, 4 Jan 2008 09:56:41 -0600, Mike Andrews
> <***@GMAIL.COM> wrote:
>
> >The issue is that you're creating a new Report via this line:
> >
> >Dim rpt As New BaseReport
> >
> >and then destroying it and in place of it setting an existing one:
> >
> >rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> >
> >since the list box contains the references to the report object, and
> you've
> >previously disposed it it will fail to run.
> >You need to refrain from calling the dispose() method until you're done
> with
> >the form in which the listbox resides.
> >You can then dispose all of the reports.
>
> Bingo, the Reports object should be responsible for disposing what it
> aggregates (or the owner of the Reports object if that class doesn't have
> that concept).



National Australia Bank Ltd - ABN 12 004 044 937
This email may contain confidential information. If you are not the intended
recipient, please immediately notify us at ***@nab.com.au or by replying to
the sender, and then destroy all copies of this email. Except where this email
indicates otherwise, views expressed in this email are those of the sender and not
of National Australia Bank Ltd. Advice in this email does not take account of your
objectives, financial situation, or needs. It is important for you to consider these
matters and, if the e-mail refers to a product(s), you should read the relevant
Product Disclosure Statement(s)/other disclosure document(s) before making any
decisions. If you do not want email marketing from us in future, forward this email
with "unsubscribe" in the subject line to ***@nab.com.au in order to
stop marketing emails from this sender. National Australia Bank Ltd does not
represent that this email is free of errors, viruses or interference.

[Matthew Wills]

Chris,

Obviously, as soon as I send it I remember the simpler solution...

Option Strict On

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Dim x As New Hashtable

Call x.Add("Bob", GetType(Class1))

Dim y As Type = CType(x.Item("Bob"), Type)

Dim a As Class1 = CType(Activator.CreateInstance(y), Class1)

MsgBox(TypeName(a))

End Sub
End Class

Public Class Class1


End Class

Seeya
Matthew Wills | Solution Designer | Adviser Tools and Services | Financial
Planning and Third Party | NAB Technology

Phone: [phone] | Mobile: [phone] | Email:
***@nab.com.au




Matthew
Wills/AU1/WealthM
gmt To
Discussion forum for developers
07/01/2008 09:57 using Windows Forms to build apps
AM and controls
<DOTNET-***@DISCUSS.DEVELOP.CO
M>
cc

Subject
Re: [DOTNET-WINFORMS] showdialog
and 'Cannot access a disposed
object'(Document link: Matthew
Wills)









Chris,

This probably isn't the best way, but it should point you down the right
track. Note in particular that I am populating the hashtable with the type
rather than an instance of it. Then I am pulling out the type, getting its
constructor and calling it to create the type.

Again, there is probably a better way to do this - but I pulled this
together rather quickly.

Option Strict On

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Dim x As New Hashtable

Call x.Add("Bob", GetType(Class1))

Dim y As Type = CType(x.Item("Bob"), Type)

Dim z As System.Reflection.ConstructorInfo =
y.GetConstructor(System.Type.EmptyTypes)

Dim parameters As Object() = Nothing

Dim a As Class1 = CType(z.Invoke(parameters), Class1)

MsgBox(TypeName(a))

End Sub
End Class

Public Class Class1

End Class

Seeya
Matthew Wills | Solution Designer | Adviser Tools and Services | Financial
Planning and Third Party | NAB Technology

Phone: [phone] | Mobile: [phone] | Email:
***@nab.com.au




chris Burgess
<***@GMAI
L.COM> To
Sent by: DOTNET-***@DISCUSS.DEVELOP.COM
Discussion forum cc
for developers
using Windows Subject
Forms to build Re: [DOTNET-WINFORMS] showdialog
apps and 'Cannot access a disposed
and controls object'
<DOTNET-WINFORMS@
DISCUSS.DEVELOP.C
OM>


05/01/2008 03:49
AM


Please respond to
Discussion forum
for developers
using Windows
Forms to build
apps
and controls
<DOTNET-WINFORMS@
DISCUSS.DEVELOP.C
OM>






I think what I really want is to have the report object hold the type
of report form instead of a reference to the actual form object. I
want the button to create a new form each time of the type listed in
the list box/report object, and not reference existing objects.




On Jan 4, 2008 10:53 AM, Peter Ritchie
<***@peterritchie.com> wrote:
> On Fri, 4 Jan 2008 09:56:41 -0600, Mike Andrews
> <***@GMAIL.COM> wrote:
>
> >The issue is that you're creating a new Report via this line:
> >
> >Dim rpt As New BaseReport
> >
> >and then destroying it and in place of it setting an existing one:
> >
> >rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> >
> >since the list box contains the references to the report object, and
> you've
> >previously disposed it it will fail to run.
> >You need to refrain from calling the dispose() method until you're done
> with
> >the form in which the listbox resides.
> >You can then dispose all of the reports.
>
> Bingo, the Reports object should be responsible for disposing what it
> aggregates (or the owner of the Reports object if that class doesn't have
> that concept).




National Australia Bank Ltd - ABN 12 004 044 937
This email may contain confidential information. If you are not the intended
recipient, please immediately notify us at ***@nab.com.au or by replying to
the sender, and then destroy all copies of this email. Except where this email
indicates otherwise, views expressed in this email are those of the sender and not
of National Australia Bank Ltd. Advice in this email does not take account of your
objectives, financial situation, or needs. It is important for you to consider these
matters and, if the e-mail refers to a product(s), you should read the relevant
Product Disclosure Statement(s)/other disclosure document(s) before making any
decisions. If you do not want email marketing from us in future, forward this email
with "unsubscribe" in the subject line to ***@nab.com.au in order to
stop marketing emails from this sender. National Australia Bank Ltd does not
represent that this email is free of errors, viruses or interference.

[Mike Andrews]

If you need to be able to specify a type for the "form" and then create it
if it's not been created yet or show it if it has, you can use generics to
your advantage here.

Create a method called CreateForm(Of T) or some such name like this:

Public Class BaseForm
Inherits System.Windows.Forms.Form
End Class
Private ShownForms As New Dictionary(Of String, BaseForm)
Public Function CreateForm(Of ItemType As {BaseForm, New})() As ItemType
Dim form As ItemType
Dim key As String = GetType(ItemType).Name
If Not ShownForms.ContainsKey(key) Then
form = New ItemType()
'Set other form parameters here
ShownForms.Add(key, form)
Else
form = CType(ShownForms(key), ItemType)
End If
Return form
End Function


On Jan 4, 2008 9:28 AM, chris Burgess <***@gmail.com> wrote:

> I have the following code to launch forms based upon a selection from
> a list box:
>
> Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e
> As System.EventArgs) Handles LoadReport.Click
> Dim rpt As New BaseReport
> rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> rpt.ShowDialog()
> rpt.Dispose()
> End Sub
>
> 'Reports' is a list box that contains 'Report' objects. The Report
> object has a report name property (the DisplayMember) and a report
> form property, each of which is derived from BaseForm (the
> .valuemember).
>
> If I launch a report form, close it, then try to launch it again, I
> get an error:
>
> System.ObjectDisposedException was unhandled
> Message="Cannot access a disposed object.
> Object name: 'Report_OrdersByDate'."
> ObjectName="Report_OrdersByDate"
> Source="System.Windows.Forms"
> StackTrace:
> at System.Windows.Forms.Control.CreateHandle()
> at System.Windows.Forms.Form.CreateHandle()
> at System.Windows.Forms.Control.get_Handle()
> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> at System.Windows.Forms.Form.ShowDialog()
> at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
> e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
> at System.Windows.Forms.Control.OnClick(EventArgs e)
> at System.Windows.Forms.Button.OnClick(EventArgs e)
> at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
> at System.Windows.Forms.Control.WmMouseUp(Message& m,
> MouseButtons button, Int32 clicks)
> at System.Windows.Forms.Control.WndProc(Message& m)
> at System.Windows.Forms.ButtonBase.WndProc(Message& m)
> at System.Windows.Forms.Button.WndProc(Message& m)
> at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> m)
> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
> m)
> at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
> hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
> msg)
> at
> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop
> (Int32
> dwComponentID, Int32 reason, Int32 pvLoopData)
> at
> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Application.ThreadContext.RunMessageLoop
> (Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Application.Run(ApplicationContext context)
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun
> ()
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel
> ()
> at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run
> (String[]
> commandLine)
> at Converse.My.MyApplication.Main(String[] Args) in
> 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
> at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
> args)
> at System.AppDomain.ExecuteAssembly(String assemblyFile,
> Evidence assemblySecurity, String[] args)
> at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
> at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
> at System.Threading.ExecutionContext.Run(ExecutionContext
> executionContext, ContextCallback callback, Object state)
> at System.Threading.ThreadHelper.ThreadStart()
>

[chris Burgess]

Hi Mike:

This is what I need.

Thanks!

Chris

On Jan 7, 2008 8:49 AM, Mike Andrews <***@gmail.com> wrote:
> If you need to be able to specify a type for the "form" and then create it
> if it's not been created yet or show it if it has, you can use generics to
> your advantage here.
>
> Create a method called CreateForm(Of T) or some such name like this:
>
> Public Class BaseForm
> Inherits System.Windows.Forms.Form
> End Class
> Private ShownForms As New Dictionary(Of String, BaseForm)
> Public Function CreateForm(Of ItemType As {BaseForm, New})() As ItemType
> Dim form As ItemType
> Dim key As String = GetType(ItemType).Name
> If Not ShownForms.ContainsKey(key) Then
> form = New ItemType()
> 'Set other form parameters here
> ShownForms.Add(key, form)
> Else
> form = CType(ShownForms(key), ItemType)
> End If
> Return form
> End Function
>
>
> On Jan 4, 2008 9:28 AM, chris Burgess <***@gmail.com> wrote:
>
>
> > I have the following code to launch forms based upon a selection from
> > a list box:
> >
> > Private Sub LoadReport_Click(ByVal sender As System.Object, ByVal e
> > As System.EventArgs) Handles LoadReport.Click
> > Dim rpt As New BaseReport
> > rpt = DirectCast(Me.Reports.SelectedValue, BaseReport)
> > rpt.ShowDialog()
> > rpt.Dispose()
> > End Sub
> >
> > 'Reports' is a list box that contains 'Report' objects. The Report
> > object has a report name property (the DisplayMember) and a report
> > form property, each of which is derived from BaseForm (the
> > .valuemember).
> >
> > If I launch a report form, close it, then try to launch it again, I
> > get an error:
> >
> > System.ObjectDisposedException was unhandled
> > Message="Cannot access a disposed object.
> > Object name: 'Report_OrdersByDate'."
> > ObjectName="Report_OrdersByDate"
> > Source="System.Windows.Forms"
> > StackTrace:
> > at System.Windows.Forms.Control.CreateHandle()
> > at System.Windows.Forms.Form.CreateHandle()
> > at System.Windows.Forms.Control.get_Handle()
> > at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> > at System.Windows.Forms.Form.ShowDialog()
> > at Converse.MainMenu.LoadReport_Click(Object sender, EventArgs
> > e) in C:\Work\StoreReporter\StoreReporter\MainMenu.vb:line 48
> > at System.Windows.Forms.Control.OnClick(EventArgs e)
> > at System.Windows.Forms.Button.OnClick(EventArgs e)
> > at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
> > at System.Windows.Forms.Control.WmMouseUp(Message& m,
> > MouseButtons button, Int32 clicks)
> > at System.Windows.Forms.Control.WndProc(Message& m)
> > at System.Windows.Forms.ButtonBase.WndProc(Message& m)
> > at System.Windows.Forms.Button.WndProc(Message& m)
> > at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> > m)
> > at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
> > m)
> > at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr
> > hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
> > at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
> > msg)
> > at
> > System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop
> > (Int32
> > dwComponentID, Int32 reason, Int32 pvLoopData)
> > at
> > System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> > reason, ApplicationContext context)
> > at System.Windows.Forms.Application.ThreadContext.RunMessageLoop
> > (Int32
> > reason, ApplicationContext context)
> > at System.Windows.Forms.Application.Run(ApplicationContext context)
> > at
> > Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun
> > ()
> > at
> > Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel
> > ()
> > at
> > Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run
> > (String[]
> > commandLine)
> > at Converse.My.MyApplication.Main(String[] Args) in
> > 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
> > at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
> > args)
> > at System.AppDomain.ExecuteAssembly(String assemblyFile,
> > Evidence assemblySecurity, String[] args)
> > at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
> > at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
> > at System.Threading.ExecutionContext.Run(ExecutionContext
> > executionContext, ContextCallback callback, Object state)
> > at System.Threading.ThreadHelper.ThreadStart()
> >
>

[chris Burgess]

How do I pass the report type (derived from BaseForm) to the CreateForm class?

To create the form, I have this:
Public Function CreateForm(Of ItemType As {BaseForm, New})() As ItemType
Return New ItemType
End Function

I created two forms derived from BaseForm called ChildForm1, ChildForm2

if I do this:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As BaseForm
f = CreateForm(Of ChildForm1)()
f.ShowDialog()
End Sub

It works fine.

What I'd like to do is something like this:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As BaseForm
Dim reports As New List(Of BaseForm)
reports.Add(childform1)
reports.Add(ChildForm2)

f = CreateForm(Of reports.item(0))()

' Or
' Dim r As BaseForm = reports.Item(0)
' f = CreateForm(Of r)()

f.ShowDialog()
End Sub

Or something like that. I don't understand what I need to pass to the
CreateForm function.









On Jan 7, 2008 8:49 AM, Mike Andrews <***@gmail.com> wrote:
> If you need to be able to specify a type for the "form" and then create it
> if it's not been created yet or show it if it has, you can use generics to
> your advantage here.
>
> Create a method called CreateForm(Of T) or some such name like this:
>
> Public Class BaseForm
> Inherits System.Windows.Forms.Form
> End Class
> Private ShownForms As New Dictionary(Of String, BaseForm)
> Public Function CreateForm(Of ItemType As {BaseForm, New})() As ItemType
> Dim form As ItemType
> Dim key As String = GetType(ItemType).Name
> If Not ShownForms.ContainsKey(key) Then
> form = New ItemType()
> 'Set other form parameters here
> ShownForms.Add(key, form)
> Else
> form = CType(ShownForms(key), ItemType)
> End If
> Return form
> End Function
>
>

[Peter Osucha]

I have been searching for info on what actually will cause a
WriteTimeout error to happen on a serialport object in net 2.0. There
are lots of articles that talk about a Write operation not being able to
complete in the time allotted. However, besides having a series of
bytes to be written that when taking into the account the baud rate
cannot complete in the allotted time, I can't think of another reason
for this error to occur - nor can I find reference to when it will
occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Don Clark]

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Peter Osucha]

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Benny Skjold Tordrup]

Does the physical port settings match the settings that you apply in code?

Med venlig hilsen / Best regards

Benny Tordrup
System Developer

Microsoft Certified Technology Specialist



-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 04:28
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Peter Osucha]

Benny, I'm not sure what you mean by this. The port can handle the baud rate and all lines (for the 9 pin rs-232 spec) are connected. Is this what you meant?

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Benny Skjold Tordrup
Sent: Tuesday, January 08, 2008 10:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Does the physical port settings match the settings that you apply in code?

Med venlig hilsen / Best regards

Benny Tordrup
System Developer

Microsoft Certified Technology Specialist



-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 04:28
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Benny Skjold Tordrup]

Peter,

Try the command "mode com1" (or what ever com port you use) in a cmd shell.
What settings are returned? Do they match the settings you want to use from
your code?

Med venlig hilsen / Best regards





-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 14:23
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Benny, I'm not sure what you mean by this. The port can handle the baud
rate and all lines (for the 9 pin rs-232 spec) are connected. Is this what
you meant?

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Benny
Skjold Tordrup
Sent: Tuesday, January 08, 2008 10:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Does the physical port settings match the settings that you apply in code?

Med venlig hilsen / Best regards

Benny Tordrup
System Developer

Microsoft Certified Technology Specialist



-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 04:28
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Peter Osucha]

Guys,

Thanks for all the suggestions. I tried them all - and was still stuck. The 'mode' commands all looked good, etc.

The one thing no one suggested (:-)) was to look at the hardware - specifically the cables and connectors. The target here is an SBC that has all four comports available by way of a 40 pin ribbon cable header. The header was broken - thereby only allowing intermittent connection of the Com port signals.

Once I changed the connector, the original app communicated over the ports just fine.

Again, thanks for all the help. If nothing else, it was a good learning experience for serial port communication.

Peter


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Benny Skjold Tordrup
Sent: Wednesday, January 09, 2008 11:01 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Peter,

Try the command "mode com1" (or what ever com port you use) in a cmd shell.
What settings are returned? Do they match the settings you want to use from
your code?

Med venlig hilsen / Best regards





-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 14:23
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Benny, I'm not sure what you mean by this. The port can handle the baud
rate and all lines (for the 9 pin rs-232 spec) are connected. Is this what
you meant?

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Benny
Skjold Tordrup
Sent: Tuesday, January 08, 2008 10:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SV: [DOTNET-WINFORMS] SerialPort.WriteTimout

Does the physical port settings match the settings that you apply in code?

Med venlig hilsen / Best regards

Benny Tordrup
System Developer

Microsoft Certified Technology Specialist



-----Oprindelig meddelelse-----
Fra: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] På vegne af Peter
Osucha
Sendt: 9. januar 2008 04:28
Til: DOTNET-***@DISCUSS.DEVELOP.COM
Emne: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Bhatnagar, Amit]

Hi All.

I am finding that my win32 call to SystemParametersInfo in my
FormClosing event handler sometimes hangs my application preventing it
from terminating. Is there a way where I could make the call but after a
timeout period then continue executing the rest of my FormClosing code?

Place this in a thread? I'd like to make the solution generic enough so
that I could timeout any method.

Any ideas?

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Don Clark]

Peter - One other thing to look for.

Is all of the data that you're transmitting to the port data that the device
can accept? Perhaps you're unknowingly sending a control string to the
device and causing it to stop receiving data. If the device stops accepting
data you'll get a timeout exception.

A couple of things that I've done to figure this out in the past.

1) Set the timeout to infinite to see if the device can accept all of the
data.
2) Use a serial port spy to see what data is being transmitted between the
serial port and the device. I use a program named Advanced Serial Port
Monitor (about $60) and it has saved me many times.

Don





-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 7:28 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[James Berry]

Portmon (sysinternals) is a free serial port monitoring tool

http://technet.microsoft.com/en-gb/sysinternals/bb896644.aspx


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: 09 January 2008 17:23
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Peter - One other thing to look for.

Is all of the data that you're transmitting to the port data that the device
can accept? Perhaps you're unknowingly sending a control string to the
device and causing it to stop receiving data. If the device stops accepting
data you'll get a timeout exception.

A couple of things that I've done to figure this out in the past.

1) Set the timeout to infinite to see if the device can accept all of the
data.
2) Use a serial port spy to see what data is being transmitted between the
serial port and the device. I use a program named Advanced Serial Port
Monitor (about $60) and it has saved me many times.

Don





-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 7:28 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Thanks, Don. I have a very small test c# (2.0) app that opens a serial
port, sets the baud rate and a few other items, and then writes a stream of
50 chars. Doesn't seem to present a problem. I have a much larger, more
complicated c# app that also writes to a serial port with similar port
settings and less characters and I keep getting a write timeout error. So
it doesn't seem to be the hardware. I am looking for other places I might
have screwed up (and yes, I do know the port is open! :-)).

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Don Clark
Sent: Tuesday, January 08, 2008 5:31 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

It's not always just the length of the data and the baud rate. I've seen
write timeouts happen when using virtual serial port controls even though
given the baud rate and the length of the data there was ample time to
complete the operation. The most recent drivers for the siLabs 210x USB to
Serial chips seem to be especially slow. With a write timeout of 400ms I was
sometimes unable to write 2 characters to my device at 38400 baud.

If the write operation isn't completed during the timeout period a
timeoutexception will be thrown.

Don



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter
Osucha
Sent: Tuesday, January 08, 2008 1:58 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a WriteTimeout
error to happen on a serialport object in net 2.0. There are lots of
articles that talk about a Write operation not being able to complete in the
time allotted. However, besides having a series of bytes to be written that
when taking into the account the baud rate cannot complete in the allotted
time, I can't think of another reason for this error to occur - nor can I
find reference to when it will occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[James Berry]

Flow control plays an important part in serial communication. The receiver can indicate it is not ready to receive data by lowering the CTS line.

Best wishes
James


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Peter Osucha
Sent: 08 January 2008 21:58
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a
WriteTimeout error to happen on a serialport object in net 2.0. There
are lots of articles that talk about a Write operation not being able to
complete in the time allotted. However, besides having a series of
bytes to be written that when taking into the account the baud rate
cannot complete in the allotted time, I can't think of another reason
for this error to occur - nor can I find reference to when it will
occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Peter Osucha]

James,

Good point - thanks. I need to review the handshaking as well. Let me
look this morning...

peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
James Berry
Sent: Wednesday, January 09, 2008 5:01 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] SerialPort.WriteTimout

Flow control plays an important part in serial communication. The
receiver can indicate it is not ready to receive data by lowering the
CTS line.

Best wishes
James


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Osucha
Sent: 08 January 2008 21:58
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: [DOTNET-WINFORMS] SerialPort.WriteTimout

I have been searching for info on what actually will cause a
WriteTimeout error to happen on a serialport object in net 2.0. There
are lots of articles that talk about a Write operation not being able to
complete in the time allotted. However, besides having a series of
bytes to be written that when taking into the account the baud rate
cannot complete in the allotted time, I can't think of another reason
for this error to occur - nor can I find reference to when it will
occur.

Any ideas or places you could point me, please?

Sincerely,
Peter

[Peter Ritchie]

Are you using the SPIF_SENDCHANGE flag? This will broadcast the
WM_SETTINGCHANGE message to all windows and block SystemParametersInfo
until all windows respond. If you called SystemParametersInfo on the main
GUI thread then that thread is blocked waiting for SystemParametersInfo
and will be unable to respond to WM_SETTINGCHANGE.

[Bhatnagar, Amit]

Thanks for your reply Peter.

I don't think I am using that flag. How do I specify it? Also note that
the call to SystemParametersInfo doesn't always hang the app, but it
does it enough that I want to ensure that the application will indeed
termiante (hence my question about timing out this call).



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Friday, January 11, 2008 1:12 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Allowing a method to timeout

Are you using the SPIF_SENDCHANGE flag? This will broadcast the
WM_SETTINGCHANGE message to all windows and block SystemParametersInfo
until all windows respond. If you called SystemParametersInfo on the
main GUI thread then that thread is blocked waiting for
SystemParametersInfo and will be unable to respond to WM_SETTINGCHANGE.

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

You'd be sending that flag if the second bit of the fWinIni (last)
parameter is set. My guess is that depending on the setting your
changing, Windows may send a WM_SETTINGCHANGE message regardless of what
you send in here.

You can verify that with Spy++ and watch for WM_SETTINGCHANGE when you can
SystemParameterInfo.

If that's what's causing the hang, then calling it on a background thread
will avoid the problem. You'll have to deal with communicating back to
the main GUI thread that SystemParameterInfo has returned and what the
return value is.

If you are setting the second bit of fWinIni high, you can avoid the
problem by not doing that and broadcast WM_SETTINGCHANGE with
SendMessageTimeout...

[Bhatnagar, Amit]

The value I am passing in for fWinIni is 0, so I guess that
SPIF_SENDCHANGE is not being set. So then make my call to
SystemParameterInfo on a background thread?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Friday, January 11, 2008 1:35 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Allowing a method to timeout

You'd be sending that flag if the second bit of the fWinIni (last)
parameter is set. My guess is that depending on the setting your
changing, Windows may send a WM_SETTINGCHANGE message regardless of what
you send in here.

You can verify that with Spy++ and watch for WM_SETTINGCHANGE when you
can SystemParameterInfo.

If that's what's causing the hang, then calling it on a background
thread will avoid the problem. You'll have to deal with communicating
back to the main GUI thread that SystemParameterInfo has returned and
what the return value is.

If you are setting the second bit of fWinIni high, you can avoid the
problem by not doing that and broadcast WM_SETTINGCHANGE with
SendMessageTimeout...

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Bhatnagar, Amit]

OK, now I am confused.

I looked at the Windows messages being received by my application's main
window and some child windows. Neither receives the WM_SETTINGCHANGE
method when I can SystemParameterInfo.

Also, I changed the call to SystemParameterInfo to run on a background
thread, and terminate after a specified timeout. In some cases it does
timeout and Abort() gets called on the thread, yet it is still hanging
on the call to SystemParameterInfo.

any ideas?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Friday, January 11, 2008 1:35 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Allowing a method to timeout

You'd be sending that flag if the second bit of the fWinIni (last)
parameter is set. My guess is that depending on the setting your
changing, Windows may send a WM_SETTINGCHANGE message regardless of what
you send in here.

You can verify that with Spy++ and watch for WM_SETTINGCHANGE when you
can SystemParameterInfo.

If that's what's causing the hang, then calling it on a background
thread will avoid the problem. You'll have to deal with communicating
back to the main GUI thread that SystemParameterInfo has returned and
what the return value is.

If you are setting the second bit of fWinIni high, you can avoid the
problem by not doing that and broadcast WM_SETTINGCHANGE with
SendMessageTimeout...

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Bhatnagar, Amit]

I have made a service to timeout a method call by launching a delegate
asynchronously via BeginInvoke. The documentation states, indirectly,
that the call to BeginInvoke should be followed by a call to EndInvoke
to prevent leaks. However, I am not sure if the call to EndInvoke is
required should the delegate timeout because the call to EndInvoke will
block the thread and wait for the delegate to complete. So I think what
I have is OK, but can anyone confirm if the call to EndInvoke is
required if it timesout?

See the following code:

---
IAsyncResult asyncResult = d.BeginInvoke(null, new object());

if (asyncResult.AsyncWaitHandle.WaitOne(7000, true))
{
// Not timed out...
d.EndInvoke(asyncResult);
}

else
{
//Timed out ... EndInvoke required here?
}

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

The only EndInvoke that I know of where you're not "required" to call it
is Control.EndInvoke.

See the comments in
http://blogs.msdn.com/cbrumme/archive/2003/05/06/51385.aspx

There are various object that are kept around until EndInvoke is called,
depending on the delegate this may include return value, exception(s),
state, etc.

In your timed-out case, you'll force the thread to block until the
delegate has completed running, which probably defeats the purpose of
timing-out.

You could spawn another thread that waits on the AsyncWaitHandle and
simply calls EndInvoke when it becomes signaled. That way you free your
current thread to time-out and the EndInvoke is handled in the
background. It could very well be there's an example of this somewhere...

On Tue, 15 Jan 2008 10:17:09 -0700, Bhatnagar, Amit
<***@GDCANADA.COM> wrote:

>I have made a service to timeout a method call by launching a delegate
>asynchronously via BeginInvoke. The documentation states, indirectly,
>that the call to BeginInvoke should be followed by a call to EndInvoke
>to prevent leaks. However, I am not sure if the call to EndInvoke is
>required should the delegate timeout because the call to EndInvoke will
>block the thread and wait for the delegate to complete. So I think what
>I have is OK, but can anyone confirm if the call to EndInvoke is
>required if it timesout?
>
>See the following code:
>
>---
>IAsyncResult asyncResult = d.BeginInvoke(null, new object());
>
>if (asyncResult.AsyncWaitHandle.WaitOne(7000, true))
>{
> // Not timed out...
> d.EndInvoke(asyncResult);
>}
>
>else
>{
> //Timed out ... EndInvoke required here?
>}
>

[Bhatnagar, Amit]

Thanks for your response.

Do you know if the AsyncCallback would get called if it times out? If
so, then I could pass the delegate down to the callback and call
EndInvoke.

Every example of timing out a method, using BeginInvoke and EndInvoke,
doesn't make a call to EndInvoke in the timed-out case.

see:
http://www.ondotnet.com/pub/a/dotnet/2003/02/24/asyncdelegates.html
http://www.eggheadcafe.com/tutorials/aspnet/847c94bf-4b8d-4a66-9ae5-5b61
f049019f/basics-make-any-method-c.aspx


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Tuesday, January 15, 2008 11:08 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

The only EndInvoke that I know of where you're not "required" to call it
is Control.EndInvoke.

See the comments in
http://blogs.msdn.com/cbrumme/archive/2003/05/06/51385.aspx

There are various object that are kept around until EndInvoke is called,
depending on the delegate this may include return value, exception(s),
state, etc.

In your timed-out case, you'll force the thread to block until the
delegate has completed running, which probably defeats the purpose of
timing-out.

You could spawn another thread that waits on the AsyncWaitHandle and
simply calls EndInvoke when it becomes signaled. That way you free your
current thread to time-out and the EndInvoke is handled in the
background. It could very well be there's an example of this
somewhere...

On Tue, 15 Jan 2008 10:17:09 -0700, Bhatnagar, Amit
<***@GDCANADA.COM> wrote:

>I have made a service to timeout a method call by launching a delegate
>asynchronously via BeginInvoke. The documentation states, indirectly,
>that the call to BeginInvoke should be followed by a call to EndInvoke
>to prevent leaks. However, I am not sure if the call to EndInvoke is
>required should the delegate timeout because the call to EndInvoke will

>block the thread and wait for the delegate to complete. So I think what

>I have is OK, but can anyone confirm if the call to EndInvoke is
>required if it timesout?
>
>See the following code:
>
>---
>IAsyncResult asyncResult = d.BeginInvoke(null, new object());
>
>if (asyncResult.AsyncWaitHandle.WaitOne(7000, true)) {
> // Not timed out...
> d.EndInvoke(asyncResult);
>}
>
>else
>{
> //Timed out ... EndInvoke required here?
>}
>

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

In Richard's example (pg 2), he shows using the BeginInvoke overload that
takes the AsyncCallback which calls some method when the call completes.
In there, as Richard details, you can call EndInvoke. The AsyncCallback
is called on a ThreadPool thread. If you're looking to avoid stress on
the threadpool, using your own thread to wait on the wait handle may be a
better option. Using the AsyncCallback means creating a type to keep
track of the delegate reference in order to call its BeginInvoke. It's up
to you how complicated you want to be if stressing the threadpool isn't an
issue.

Peter's example has a leak.

[Bhatnagar, Amit]

The AsyncCallback doesn't get called if the delegate times out, so there
is no way to call EndInvoke.

Is my only option then to create another thread and wait for a signal
and then call EndInvoke like you suggested in your previous post? An
example of that scenario would be handy.

How bad would not calling EndInvoke in the timed-out case really be?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Tuesday, January 15, 2008 11:43 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

In Richard's example (pg 2), he shows using the BeginInvoke overload
that takes the AsyncCallback which calls some method when the call
completes.
In there, as Richard details, you can call EndInvoke. The AsyncCallback
is called on a ThreadPool thread. If you're looking to avoid stress on
the threadpool, using your own thread to wait on the wait handle may be
a better option. Using the AsyncCallback means creating a type to keep
track of the delegate reference in order to call its BeginInvoke. It's
up to you how complicated you want to be if stressing the threadpool
isn't an issue.

Peter's example has a leak.

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Bhatnagar, Amit]

When I try calling EndInvoke in the AsyncCallback, as described on page
2 of Richard's example, I get an InvalidCastException when trying to
cast the AsyncState to my delegate. He shows a work around (Code Example
11), but that doesn't seem to work on the 2.0 version of the framework.

Any ideas?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Tuesday, January 15, 2008 11:43 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

In Richard's example (pg 2), he shows using the BeginInvoke overload
that takes the AsyncCallback which calls some method when the call
completes.
In there, as Richard details, you can call EndInvoke. The AsyncCallback
is called on a ThreadPool thread. If you're looking to avoid stress on
the threadpool, using your own thread to wait on the wait handle may be
a better option. Using the AsyncCallback means creating a type to keep
track of the delegate reference in order to call its BeginInvoke. It's
up to you how complicated you want to be if stressing the threadpool
isn't an issue.

Peter's example has a leak.

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Bhatnagar, Amit]

grr.. I was just missing a

using System.Runtime.Remoting.Messaging

statement.

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Bhatnagar, Amit
Sent: Tuesday, January 15, 2008 1:53 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

When I try calling EndInvoke in the AsyncCallback, as described on page
2 of Richard's example, I get an InvalidCastException when trying to
cast the AsyncState to my delegate. He shows a work around (Code Example
11), but that doesn't seem to work on the 2.0 version of the framework.

Any ideas?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Tuesday, January 15, 2008 11:43 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

In Richard's example (pg 2), he shows using the BeginInvoke overload
that takes the AsyncCallback which calls some method when the call
completes.
In there, as Richard details, you can call EndInvoke. The AsyncCallback
is called on a ThreadPool thread. If you're looking to avoid stress on
the threadpool, using your own thread to wait on the wait handle may be
a better option. Using the AsyncCallback means creating a type to keep
track of the delegate reference in order to call its BeginInvoke. It's
up to you how complicated you want to be if stressing the threadpool
isn't an issue.

Peter's example has a leak.

The information contained in this e-mail message is PRIVATE. It may
contain confidential information and may be legally privileged. It is
intended for the exclusive use of the addressee(s). If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution or reproduction of this communication is strictly
prohibited. If the intended recipient(s) cannot be reached or if a
transmission problem has occurred, please notify the sender immediately
by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

The delegate doesn't time out, the code waiting for the asynchronous
delegate times out (i.e. the code calling WaitOne()). Despite that "time-
out" the delegate is sill running and will call the AsynCallback when it's
done.

[Bhatnagar, Amit]

Well then I don't see how this approach helps me out then. My motivation
for doing this was to not get tied up when my call to
SystemParametersInfo doesn't return as per my previous thread.

(No WM_SETTINGCHANGE message received by my windows as verified by
spy++)

If this delegate never returns in this case, then won't I have one
thread in the pool that will just hang? Is there no way to terminate
this delegate after the time out period?



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Tuesday, January 15, 2008 12:25 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

The delegate doesn't time out, the code waiting for the asynchronous
delegate times out (i.e. the code calling WaitOne()). Despite that
"time- out" the delegate is sill running and will call the AsynCallback
when it's done.

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Fabian Schmied]

> Well then I don't see how this approach helps me out then. My motivation
> for doing this was to not get tied up when my call to
> SystemParametersInfo doesn't return as per my previous thread.

Amit, your actual problem is that of SystemParametersInfo not
returning. You should really look into that rather than trying to work
around it. As Peter said: Call product support to find out what's
happening there. SystemParametersInfo is not supposed to hang
infinitely. Terminating the thread that called it might cure the
symptom, but you definitely have a bigger problem.

(As a side note, I don't really know much about SystemParametersInfo,
but maybe you should ask at a Win32 forum as well - somebody might
have had this issue before. There's also this posting by Raymond Chen:
http://blogs.msdn.com/oldnewthing/archive/2005/03/10/392118.aspx - he
also talks about the WM_SETTINGCHANGE message; but it doesn't have to
be your own window that is blocking, it might be a different one.)

Regarding your workaround: yes, you need to call EndInvoke when
invoking delegates asynchronously. And if SystemParametersInfo blocks
infinitely, the approach with AsyncCallback calling EndInvoke won't do
that, either.

You could try to spawn your own thread and abort it after a certain
amount of time, but without knowing why/where SystemParametersInfo is
blocking, there's no way of telling whether Abort will actually be
able to terminate the thread. IMO, you should try to resolve the root
cause instead, otherwise you'll end up leaking background threads.

Best regards,
Fabian

[Peter Ritchie]

On Tue, 15 Jan 2008 12:50:15 -0700, Bhatnagar, Amit
<***@GDCANADA.COM> wrote:

>Well then I don't see how this approach helps me out then. My motivation
>for doing this was to not get tied up when my call to
>SystemParametersInfo doesn't return as per my previous thread.

If you're looking for an ability for one thread to not be blocked by
another, this will suit your needs. If you're looking to terminate a
thread when a blocked call is taking too long, this will not do what you
want.

Asynchronous delegates use threadpool threads, there's no reliable way to
terminate a threadpool thread.

>
>(No WM_SETTINGCHANGE message received by my windows as verified by
>spy++)

That sounds serious, I would suggest contacting PSS about that. Can you
provide code that reproduces the problem?

>
>If this delegate never returns in this case, then won't I have one
>thread in the pool that will just hang?

Yes.

>Is there no way to terminate
>this delegate after the time out period?

No, see above.

[Peter Ritchie]

On Wed, 16 Jan 2008 10:12:22 +0100, Fabian Schmied <***@GMX.AT>
wrote:
>(As a side note, I don't really know much about SystemParametersInfo,
>but maybe you should ask at a Win32 forum as well - somebody might
>have had this issue before. There's also this posting by Raymond Chen:
>http://blogs.msdn.com/oldnewthing/archive/2005/03/10/392118.aspx - he
>also talks about the WM_SETTINGCHANGE message; but it doesn't have to
>be your own window that is blocking, it might be a different one.)

Amit mentioned that he wasn't using the flag that causes the send of
WM_SETTINGCHANGE; so I can see no reason why it would hang... Seeing the
code might be useful...

[Bhatnagar, Amit]

Here is the relevant code snippets, like I said, this works most of the
time, but sometimes it hangs.

// The SPI_GETNONCLIENTMETRICS call only gets called once at
initialization,
// setting the touch screen size and hanging on to them.

m_standardNonClientMetrics = new NONCLIENTMETRICS();

m_standardNonClientMetrics.cbSize =
Marshal.SizeOf(typeof(NONCLIENTMETRICS));

bool result = SystemParametersInfo(SPI_GETNONCLIENTMETRICS,

m_standardNonClientMetrics.cbSize,
ref
m_standardNonClientMetrics,
0);

m_standardNonClientMetrics.scrollHeight = SCROLLBAR_HEIGHT;
m_standardNonClientMetrics.scrollWidth = SCROLLBAR_WIDTH;

m_touchScreenNonClientMetrics = new NONCLIENTMETRICS();
m_touchScreenNonClientMetrics = m_standardNonClientMetrics;

m_touchScreenNonClientMetrics.scrollWidth =
TS_SCROLLBAR_WIDTH;
m_touchScreenNonClientMetrics.scrollHeight =
TS_SCROLLBAR_HEIGHT;


// Increase the size of the scrollbars here.
result =
SystemParametersInfo(SPI_SETNONCLIENTMETRICS,

m_touchScreenNonClientMetrics.cbSize,
ref m_touchScreenNonClientMetrics,
0);


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Wednesday, January 16, 2008 3:08 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

On Wed, 16 Jan 2008 10:12:22 +0100, Fabian Schmied
<***@GMX.AT>
wrote:
>(As a side note, I don't really know much about SystemParametersInfo,
>but maybe you should ask at a Win32 forum as well - somebody might have

>had this issue before. There's also this posting by Raymond Chen:
>http://blogs.msdn.com/oldnewthing/archive/2005/03/10/392118.aspx - he
>also talks about the WM_SETTINGCHANGE message; but it doesn't have to
>be your own window that is blocking, it might be a different one.)

Amit mentioned that he wasn't using the flag that causes the send of
WM_SETTINGCHANGE; so I can see no reason why it would hang... Seeing
the code might be useful...

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Bhatnagar, Amit]

I think I incorrectly passed in the wrong param for uiParam. I am
passing in .cbSize and the example on Pinvoke.net has it being 0..
(although I could have sworn that pinvoke.net is where I originally got
my sample from!)..

could this cause the hang?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Bhatnagar, Amit
Sent: Wednesday, January 16, 2008 3:29 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

Here is the relevant code snippets, like I said, this works most of the
time, but sometimes it hangs.

// The SPI_GETNONCLIENTMETRICS call only gets called once at
initialization,
// setting the touch screen size and hanging on to them.

m_standardNonClientMetrics = new NONCLIENTMETRICS();

m_standardNonClientMetrics.cbSize =
Marshal.SizeOf(typeof(NONCLIENTMETRICS));

bool result = SystemParametersInfo(SPI_GETNONCLIENTMETRICS,

m_standardNonClientMetrics.cbSize,
ref
m_standardNonClientMetrics,
0);

m_standardNonClientMetrics.scrollHeight = SCROLLBAR_HEIGHT;
m_standardNonClientMetrics.scrollWidth = SCROLLBAR_WIDTH;

m_touchScreenNonClientMetrics = new NONCLIENTMETRICS();
m_touchScreenNonClientMetrics = m_standardNonClientMetrics;

m_touchScreenNonClientMetrics.scrollWidth =
TS_SCROLLBAR_WIDTH;
m_touchScreenNonClientMetrics.scrollHeight =
TS_SCROLLBAR_HEIGHT;


// Increase the size of the scrollbars here.
result =
SystemParametersInfo(SPI_SETNONCLIENTMETRICS,

m_touchScreenNonClientMetrics.cbSize,
ref m_touchScreenNonClientMetrics,
0);


-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Wednesday, January 16, 2008 3:08 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

On Wed, 16 Jan 2008 10:12:22 +0100, Fabian Schmied
<***@GMX.AT>
wrote:
>(As a side note, I don't really know much about SystemParametersInfo,
>but maybe you should ask at a Win32 forum as well - somebody might have

>had this issue before. There's also this posting by Raymond Chen:
>http://blogs.msdn.com/oldnewthing/archive/2005/03/10/392118.aspx - he
>also talks about the WM_SETTINGCHANGE message; but it doesn't have to
>be your own window that is blocking, it might be a different one.)

Amit mentioned that he wasn't using the flag that causes the send of
WM_SETTINGCHANGE; so I can see no reason why it would hang... Seeing
the code might be useful...

The information contained in this e-mail message is PRIVATE. It may
contain confidential information and may be legally privileged. It is
intended for the exclusive use of the addressee(s). If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution or reproduction of this communication is strictly
prohibited. If the intended recipient(s) cannot be reached or if a
transmission problem has occurred, please notify the sender immediately
by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

The documentation for SystemParametersInfo details sending the cbSize
value for SPI_{G|S}ETCLIENTMETRICS; but I tried with 0 and it seems to
work too (the same value is in NONCLIENTMETRICS, so it doesn't *need* it).

Okay, a little bit of testing shows that SystemParametersInfo (at least
with SPI_SETCLIENTMETRICS) is blocking, but it doesn't block the GUI
thread and it continues to pump messages. In my test, while blocked on
the SystemParametersInfo(SPI_SETCLIENTMETRICS) the thread received the
following messages:
WM_WINDOWPOSCHANGING
WM_GETMINMAXINFO
WM_NCCALCSIZE
WM_WINDOPOSCHANGED

You can certainly get in a situation--since a function call is blocked and
messages can come in on the same thread while that's blocked--where you
can cause a hang.

[Bhatnagar, Amit]

Thanks Peter for looking into this.

Well what I don't get is that it never hangs during my app's
initialization (where we get the current NC metrics), nor does it hang
when I minimize the app (where I restore the NC metrics). The only call
that causes it to hang is during shutdown. I have tried moving this from
my MainWindow's FormClosing event out into a call just after
RunApplication() returns, but that also sometimes hangs (process still
lives, main window is gone.) Isn't that odd? Shouldn't the window be
destroyed by the time we return from RunApplication() and thus no
messages should cause a hang?

Either way, running the call on a async delegate at least lets my
application to close, and I am not too worried that the delegate may not
return and cause a thread from the pool to hang because the application
is closing anyhow.

Not the best way to do things, but it'll do for now.

Do you know if .NET 3.5 has a better way of doing things? Is there
finally a .NET API to access these system settings?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
Peter Ritchie
Sent: Wednesday, January 16, 2008 7:19 PM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.

The documentation for SystemParametersInfo details sending the cbSize
value for SPI_{G|S}ETCLIENTMETRICS; but I tried with 0 and it seems to
work too (the same value is in NONCLIENTMETRICS, so it doesn't *need*
it).

Okay, a little bit of testing shows that SystemParametersInfo (at least
with SPI_SETCLIENTMETRICS) is blocking, but it doesn't block the GUI
thread and it continues to pump messages. In my test, while blocked on
the SystemParametersInfo(SPI_SETCLIENTMETRICS) the thread received the
following messages:
WM_WINDOWPOSCHANGING
WM_GETMINMAXINFO
WM_NCCALCSIZE
WM_WINDOPOSCHANGED

You can certainly get in a situation--since a function call is blocked
and messages can come in on the same thread while that's blocked--where
you can cause a hang.

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

[Peter Ritchie]

Maybe you're calling SystemParametersInfo during a message that does block
the message pump? I'd have to check, but I could see a windows message
pump not processing any messages while the application was processing
WM_CLOSE, for example.


On Thu, 17 Jan 2008 08:44:06 -0700, Bhatnagar, Amit
<***@GDCANADA.COM> wrote:

>Thanks Peter for looking into this.
>
>Well what I don't get is that it never hangs during my app's
>initialization (where we get the current NC metrics), nor does it hang
>when I minimize the app (where I restore the NC metrics). The only call
>that causes it to hang is during shutdown. I have tried moving this from
>my MainWindow's FormClosing event out into a call just after
>RunApplication() returns, but that also sometimes hangs (process still
>lives, main window is gone.) Isn't that odd? Shouldn't the window be
>destroyed by the time we return from RunApplication() and thus no
>messages should cause a hang?
>
>Either way, running the call on a async delegate at least lets my
>application to close, and I am not too worried that the delegate may not
>return and cause a thread from the pool to hang because the application
>is closing anyhow.
>
>Not the best way to do things, but it'll do for now.
>
>Do you know if .NET 3.5 has a better way of doing things? Is there
>finally a .NET API to access these system settings?
>
>-----Original Message-----
>From: Discussion forum for developers using Windows Forms to build apps
>and controls [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of
>Peter Ritchie
>Sent: Wednesday, January 16, 2008 7:19 PM
>To: DOTNET-***@DISCUSS.DEVELOP.COM
>Subject: Re: [DOTNET-WINFORMS] Delegate.BeginInvoke and EndInvoke.
>
>The documentation for SystemParametersInfo details sending the cbSize
>value for SPI_{G|S}ETCLIENTMETRICS; but I tried with 0 and it seems to
>work too (the same value is in NONCLIENTMETRICS, so it doesn't *need*
>it).
>
>Okay, a little bit of testing shows that SystemParametersInfo (at least
>with SPI_SETCLIENTMETRICS) is blocking, but it doesn't block the GUI
>thread and it continues to pump messages. In my test, while blocked on
>the SystemParametersInfo(SPI_SETCLIENTMETRICS) the thread received the
>following messages:
>WM_WINDOWPOSCHANGING
>WM_GETMINMAXINFO
>WM_NCCALCSIZE
>WM_WINDOPOSCHANGED
>
>You can certainly get in a situation--since a function call is blocked
>and messages can come in on the same thread while that's blocked--where
>you can cause a hang.
>
>The information contained in this e-mail message is PRIVATE. It may
contain confidential information and may be legally privileged. It is
intended for the exclusive use of the addressee(s). If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution or reproduction of this communication is strictly prohibited.
If the intended recipient(s) cannot be reached or if a transmission
problem has occurred, please notify the sender immediately by return e-
mail and destroy all copies of this message.
>Thank you.