Dialogs are everywhere.

As you use your computer, a lot of the windows that pop up are dialog forms. Dialogs can be the most useful type of form in a Windows Forms application, but in spite of this, the way they actually function can be confusing. I wrote the original "dialog" article here several years ago. I just rewrote it completely because I decided that it was too confusing as well, and didn't really explain them.

The key to dialogs is the fact that they're really nothing except ordinary forms that are called using the ShowDialog() method. Any form can be a dialog and dialogs that are called using the Show() method are just forms. Once you get this concept clearly in mind, they become a lot easier to understand.

The only definition I could find for a "dialog" at Microsoft was considerably different ... but then, what do they know? To see what I mean, read the completely rewritten article about dialogs:

Using Dialog Forms

That is the question!

Whether to suffer the slings and arrows of outraged C# programmers, or to take advantage of the VB.NET My.Forms object they don't have and by opposing them, end program crashes.

Virtually all advice that you will see on the web, including advice from Microsoft (largely because they haven't updated their older documentation, not because they're wrong) recommends that you instantiate a new Windows form in a multiple form application with the syntax:

Dim newForm As New AddedForm
newForm.Show()

But should you? There's another way and this article tells you all about it.

Multiple Form Instantiation in VB.NET

Murach's "core" book on programming, Visual Basic 2010 (Read the About Visual Basic review here.) contains a section about how to validate data. According to Murach, one problem with the Validating event is that once it starts, you can't exit from it again. I was a little skeptical until I tried it, but they're right!

I think I found a way around the problem. Are you a clever enough coder to find a better way? A more complete description of the challenge can be found here:

The Validating Event: A Puzzle and Challenge for VB.NET Programmers

Addendum: As documented in the comments, About Visual Basic reader Larry pointed out that I just hadn't looked hard enough. My method was pretty sneaky, but I have to admit that Larry's method is the right one to use.

While doing some reading on Microsoft's site ...

http://msdn.microsoft.com/en-us/library/system.enum.aspx

... I came across some code that I just do not understand. Maybe someone can enlighten me. It's not that I don't understand what the code is doing. What I don't understand is why Microsoft would code it that way.

Given this Enum ...

Public Enum ArrivalStatus As Integer
   Unknown = -3
   Late = -1
   OnTime = 0
   Early = 1
End Enum

Microsoft provides this statement as part of an example:

Console.WriteLine(
     "Members of {0}:",
     GetType(ArrivalStatus).Name)

The Output window will display:

Members of ArrivalStatus:

My question is, "Why the confusing and unnecessary code?" It seems to me that since the text "ArrivalStatus" is the value of the Name property and it's already required to code that text as part of Microsoft's syntax above (it won't work without it), why not just code it directly:

Console.WriteLine("Members of ArrivalStatus:")

("Name" and "name" are completely different things in their code example as well, but I suppose you might excuse that as just a style of coding.)

Do they try to make things more difficult? Or am I just not understanding something?