Comments on: .NET 2.0 WinForms multithreading and a few long days http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/ Sat, 12 Nov 2011 20:10:43 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Aaron Lerch » Blog Archive » Debugging UI http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-516 Aaron Lerch » Blog Archive » Debugging UI Mon, 15 Dec 2008 20:36:44 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-516 [...] talked before about System.Threading.SynchronizationContext, as well as BeginInvoke/InvokedRequired/IsHandleCreated. In a multi-threaded Windows Forms [...] [...] talked before about System.Threading.SynchronizationContext, as well as BeginInvoke/InvokedRequired/IsHandleCreated. In a multi-threaded Windows Forms [...]

]]> By: Windows Forms Globalization | Aaron Lerch http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-70 Windows Forms Globalization | Aaron Lerch Wed, 09 Jan 2008 03:26:17 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-70 [...] and essentially “set it and forget it”, since all Controls should be created on the same [...] [...] and essentially “set it and forget it”, since all Controls should be created on the same [...]

]]> By: windows forms Globalization - Aaron Lerch http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-69 windows forms Globalization - Aaron Lerch Wed, 09 Jan 2008 03:21:59 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-69 [...] and essentially "set it and forget it", since all Controls should be created on the same [...] [...] and essentially "set it and forget it", since all Controls should be created on the same [...]

]]> By: Occusiccaky http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-68 Occusiccaky Wed, 07 Nov 2007 06:54:47 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-68 Hello! How are you? Hello!
How are you?

]]> By: mike http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-65 mike Wed, 22 Aug 2007 23:29:31 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-65 Yeah, I didn't think my example would work, but I had to try something (since I only know about .1% of the namespace :)<BR/><BR/>Anyway, nice write up. I'm glad I didn't have to debug that! Yeah, I didn’t think my example would work, but I had to try something (since I only know about .1% of the namespace :)

Anyway, nice write up. I’m glad I didn’t have to debug that!

]]> By: aaron http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-66 aaron Wed, 22 Aug 2007 23:29:31 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-66 The DropDownItems property is fairly unique for a base class library control in how it automatically creates a child control if necessary. Most things, line context menus must be explicitly assigned. So referencing TreeView's ContextMenu would throw an null reference exception if you haven't already assigned one.<BR/><BR/>But your point is accurate in that this bug could pop up a lot where a control <I>creates</I> another control automatically. Assuming, of course, that the original underlying bug exists of a failure to marshal the execution back to the UI thread. The DropDownItems property is fairly unique for a base class library control in how it automatically creates a child control if necessary. Most things, line context menus must be explicitly assigned. So referencing TreeView’s ContextMenu would throw an null reference exception if you haven’t already assigned one.

But your point is accurate in that this bug could pop up a lot where a control creates another control automatically. Assuming, of course, that the original underlying bug exists of a failure to marshal the execution back to the UI thread.

]]> By: mike http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/comment-page-1/#comment-67 mike Wed, 22 Aug 2007 23:29:31 +0000 http://www.aaronlerch.com/blog/2007/05/19/net-20-winforms-multithreading-and-a-few-long-days/#comment-67 Did you just take a job in marketing. From the looks of the last line there, I started wondering...<BR/><BR/>Anyway, wouldn't this bug pop up in a lot of other places where a control uses another control? Like would referencing a TreeView's ContextMenu property create a new ContextMenu control under the covers automatically if it didn't already exist and then change the SynchronizationContext as you explained? If not, then I can at least say I tried ;) Did you just take a job in marketing. From the looks of the last line there, I started wondering…

Anyway, wouldn’t this bug pop up in a lot of other places where a control uses another control? Like would referencing a TreeView’s ContextMenu property create a new ContextMenu control under the covers automatically if it didn’t already exist and then change the SynchronizationContext as you explained? If not, then I can at least say I tried ;)

]]>