Here are some notes for the CBIT 2373 class on handling multiple click events in one event handler -

Private m_nFirstValue As Decimal = -1
Private m_nSecondValue As Decimal = -1

Private Sub ButtonAny_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click, Button3.Click, Button4.Click, Button5.Click, Button6.Click, Button7.Click, Button8.Click, Button9.Click, Button12.Click
      txtResult.Text &= CType(sender, Button).Text
End Sub

Private Sub btnPlus_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnPlus.Click
      m_nFirstValue = CType(txtResult.Text, Decimal)
      txtResult.Text = ""
End Sub

Private Sub btnEquals_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnEquals.Click
      m_nSecondValue = CType(txtResult.Text, Decimal)
      txtResult.Text = m_nFirstValue + m_nSecondValue
End Sub

Private Sub btnClear_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnClear.Click
      txtResult.Text = ""
      m_nFirstValue = -1
      m_nSecondValue = -1
End Sub

I have finally posted up an article I wrote on extending the new VS2005 TableAdapters into a multi-tier architecture. It is quite lengthy and shows one way of leveraging the new TableAdapter/DataSet designer in a 3-tier architecture that supports both WinForms and ASP.NET 2.0... Note that if you are creating only a WinForms client, you may want to instead just use the RowChanged event in the DataSet to do your validation, but that does not lend itself to a web environment. I subsequently did a presentation for our CNY Developer Group this month on the contents of this article.

I have finally posted up an article I wrote on extending the new VS2005 TableAdapters into a multi-tier architecture. It is quite lengthy and shows one way of leveraging the new TableAdapter/DataSet designer in a 3-tier architecture that supports both WinForms and ASP.NET 2.0... Note that if you are creating only a WinForms client, you may want to instead just use the RowChanged event in the DataSet to do your validation, but that does not lend itself to a web environment. I subsequently did a presentation for our CNY Developer Group this month on the contents of this article.

I've recently been troubleshooting a WinForms app under Citrix which had some really fluky behavior - CLR crashes, disappearing processes without errors, and missing icons. All this ended up pointing to low GDI resources, which brought back memories of Win 9x GDI limitations.

But in fact, there are still significant GDI limitations in modern version of Windows as well: Win2k has a limit of 12288 GDI handles, and Win XP/Win2k3 have a limit of 65536 GDI handles. And unfortunately, the errors are not handled well - they manifest themselves as an unstable system!

There is a great article here that has tools (with source!) to monitor GDI usage in detail -
http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/

I've had to do this just a few times in the past several years, and I keep forgetting to blog it... but here goes. If you have a hanging issue in your application, it's easy to debug by attaching to the process through VS.NET. But what if the hanging only happens on a deployed machine without VS.NET installed? You can use cordbg.exe as follows...

- copy the below files from a developer's machine (with VS.NET or .NET SDK installed) to the machine with the issue
 msvcr71.dll
 msvcp71.dll
 msdis140.dll
 cordbg.exe.config
 cordbg.exe

- the user should have a hanging .NET app currently running. If not, have them run the app and recreate the problem.

- find the PID for the app by looking in task manager (you many need to add the PID column in to view it by selecting View/Select Columns from the menu)

- start cordbg.exe from a command prompt.

- attach to the .NET process... at the (cordbg) line, enter
 a {pid}
 where {pid} is the process id you found from task manager

- you can enter "sh" to show the source code lines of the current breakpoint.

- List the loaded modules in the process using the l mod command.
 The command line is shown below:
 (cordbg) l mod

- Display and examine the call stack trace for all current threads using the *w command. This should show what line the process is hanging on (assuming the PDB file is present for the hung assembly). Specify an argument of 200; this lists up to 200 levels of stack trace.
 (cordbg) *w 200

- Now detach from the process, and quit the debugger:
 (cordbg) de
 (cordbg) q

I had been using nprof (http://nprof.sourceforge.net) to do some profiling of a WindowsForms app, but it was hitting some really odd timings on a part of the code that relied on an ActiveX EXE (don't ask).

So while searching for another profiler to get a 2nd opinion from, I found this nice “Community Edition...“ It requires registration, but integrates nicely into the IDE...

http://www.compuware.com/products/devpartner/profiler/default.asp?cid=3019X36&focus=DevPartner&source=Web+%2D+Evaluation+Request&desc=Download+%2D+%27DevPartner+Profiler+Community+Edition%27&offering=DevPartner&sf=1&p=0