12,064,546 members (54,243 online)
The About Box dialog isn't an essential part of any application, but it serves an important role, as the "dogtags" for your application.
There are two distinct, and very different, audiences for this dialog.
You definitely should have an About Box-- but to continue with the dogtag analogy, if you're whipping out dogtags on a regular basis, that's symptomatic of a deeper problem (Mediiiic!). When you do need it, it can be a lifesaver. It's OK to be used infrequently, but it also needs to provide decent diagnostic info. Decorative About Boxes with their scrolling text and 3D graphics may be fun, but they aren't helpful.
In order to serve the needs of these two vastly different user groups, my About Box provides two views: a simple, basic view for users, and a vastly more detailed view (accessible through a "More >>" button) for developers.
This form is intended to be a standalone, resuable component; simply drag and drop the AboutBox.vb file into your project, then instantiate it as you would any other form. It has no special dependencies.
Private Sub MenuItemAbout_Click(ByVal sender As System.Object,_ ByVal e As System.EventArgs) Handles MenuItemAbout.Click Dim frmAbout As New AboutBox frmAbout.ShowDialog(Me) End Sub
That provides the simplest, default About Box behavior. This should work for most applications right out of the box (as pictured in the screenshot). If you want to customize the form's behavior, it does have a number of optional properties that can be set before showing the dialog:
Public Property AppEntryAssembly() As System.Reflection.Assembly Public Property AppTitle() As String Public Property AppDescription() As String Public Property AppVersion() As String Public Property AppCopyright() As String Public Property AppImage() As Image Public Property AppMoreInfo() As String Public Property AppDetailsButton() As Boolean
The sample application demonstrates how to set these properties to customize the text in the dialog.
The primary information presented by the About Box form is automatically derived from the AssemblyInfo.* file. The AssemblyInfo.* file should always be populated for all of your assemblies as a best programming practice, but you'll want to make doubly sure in this case.
<Assembly: AssemblyTitle("About Box Demo")> <Assembly: AssemblyDescription("Demonstration of AboutBox.vb code")> <Assembly: AssemblyCompany("Atwood Heavy Industries")> <Assembly: AssemblyProduct("Demo code")> <Assembly: AssemblyCopyright("© 2004, Atwood Heavy Industries")> <Assembly: AssemblyTrademark("All Rights Reserved")>
The rest of the detailed information is gathered through .NET's built in, and very powerful, reflection capabilities.
The build date is automatically calculated for each assembly based on the Build and Revision numbers specified in the AssemblyInfo.*:
This algorithm only works if standard auto-increment values were used (as pictured):
dt = CType("01/01/2000", DateTime). _ AddDays(AssemblyVersion.Build). _ AddSeconds(AssemblyVersion.Revision * 2) If TimeZone.IsDaylightSavingTime(dt, _ TimeZone.CurrentTimeZone.GetDaylightChanges(dt.Year)) Then dt = dt.AddHours(1) End If If dt > DateTime.Now Or AssemblyVersion.Build < 730 Or _ AssemblyVersion.Revision = 0 Then dt = AssemblyLastWriteTime(a) End If
If you've overridden the Build or Revision numbers, I can't calculate build date that way. In those scenarios, I use
GetLastWriteTime on the assembly DLL file. I'm not aware of any more accurate methods to get build date, but between these two, the build time is usually correct.
RichTextBoxfor more text, so URLs and MAILTO are automatically supported in