VB6 versus WinForms
| Many of the feature changes you most need to know about aren't visual; instead, they are the things that happen in the code that you write or that is generated for you as you design and program your application. However, there are new features of the Designer as well. Table A.1 summarizes the major changes. Table A.1. VB6 versus WinForms/.NET
The DifferencesObject OrientationVisual Basic (especially versions 5.0 and 6.0) was a powerful object-oriented development tool. However, the model was vague when it came to the visual components of an application. This was especially true of forms themselves ; it was never clear whether they were classes or objects. Sometimes, they were both at once. This is not true in Visual Basic .NET and WinForms. WinForms is a fully object-oriented approach to building visual applications for Windows. It has a class library from which you build objects that present your application (mostly in the System.Windows.Forms namespace). The model is clear and consistent. InheritanceVisual Basic 6.0 offered only interface inheritance , which was necessitated by its association with COM. Interface inheritance offered Visual Basic programmers a way to implement object polymorphism , one of the three pillars of object-oriented programming. By implementing an interface, a class was signing a contract and promising to implement the methods contained therein. However, the class was fully responsible for that implementation; the interface provided only the method definitions. This ability was often the subject of heated debates: Some thought that it was a confusing addition to a straightforward language, whereas others thought that Microsoft didn't go far enough. Visual Basic .NET still offers interface inheritance (via the Implements keyword) but also allows for implementation inheritance (via the Inherits keyword). Implementation inheritance allows programmers to derive a class (now the derived class or subclass) from another class (the base class). The subclass inherits not only the method definitions of the base class but also the method implementations along with the properties and data fields. Derived classes can access members of the base class through the MyBase keyword. When you program in WinForms, this difference in inheritance will become immediately apparent. Any new form you create will derive from System.Windows.Forms.Form by default. Form, in turn , derives from another class, System.Windows.Forms.ContainerControl, and so on all the way back to System.Object, which sits at the root of all inheritance chains in .NET. This opens the door to what many call visual inheritance. You can create a new class, derived from Form, that specifies a generic layout (perhaps an OK and a Cancel button in the lower-right corner). When you derive other classes from this new class, they inherit the visual styles and controls but you can add more specific features. This makes it trivial to templatize your application; changes to the new generic base form automatically cascade to the derived classes at the next build. Custom ControlsCreating new visual controls used to involve creating a new project based on the ActiveX Control Project templates. You would have to compile the project into its own .DLL and reference it from any other projects you wished to use it for. In WinForms, on the other hand, creating a custom control is as easy as creating a class derived from System.Windows.Forms.UserControl. This class can exist inside your application project and can be used from the Toolbox or in code. See Chapter 8, Controls. Custom Control HostingThe ActiveX Control Project was very useful, but when creating a control, you had to be aware of and constantly code against its surroundings. The whole idea of an ActiveX control was that it could be hosted in a variety of contexts: a Visual Basic 6.0 project, a Word document, an HTML page, and so on. Programming to ensure seamless support for all these different hosts could be problematic at best. With classes derived from UserControl in WinForms, you only have to worry about a single host: the Common Language Runtime. Because all .NET applications (or COM applications interoperating with .NET) need to leverage the CLR, it serves as the common basis for all the code. Multiple-Language SupportQuite simply, there was none in earlier versions of Visual Basic. To use the graphical design tools, you had to write your code in Visual Basic. In contrast, WinForms is a .NET Framework library and therefore is available to any and all languages that target the Common Language Runtime: Visual Basic .NET, C#, Managed C++, J#, and so on. Multiple-Platform SupportVisual Basic was used to create Windows applications for the Windows operating systems. Microsoft Windows was the target platform. With WinForms, the CLR is the target platform. WinForms applications should run wherever a viable CLR is running. For now, this is largely the Microsoft Windows family of operating systems, but the advent of the .NET Compact Framework for mobile devices ”as well as open source, non-Windows-hosted CLR projects such as Mono ”means that WinForms applications will in the future, be able to run on a variety of physical devices. Global Application ControlTo interact with the global application properties in a Visual Basic 6 application, you used the App object. Mainly, this was for interrogating the application about its descriptive properties: name , copyright notice, version number, and so on. You could also control application-wide logging via App. The System.Windows.Forms.Application object offers a series of shared members that provide some of the same features (property interrogation ) but provide three important new features (see Chapter 11, Applications and Settings):
Advanced FeaturesYou can still interact directly with the Win32 API using a feature of .NET called interop (exposed in the System.Runtime.InteropServices namespace), but you can leverage other parts of the .NET Framework to use many techniques that used to require such access. Some major areas are as follows :
Application SettingsLocal configuration settings for applications were stored in either .INI files or the Registry. .INI files were plain text files containing a series of sections, each with a series of name/value pairs. These settings were read by the application using a reader that parsed the .INI file. In WinForms applications, local settings are stored in XML files. The main configuration file is usually named App.config. You can also use the Registry and access it via the Microsoft.Win32.Registry namespace. See Chapter 1, Hello, Windows Forms. IDE IndependenceAs you designed your application in Visual Basic 6.0, the metadata about your forms was stored in a proprietary format in .frm files. In theory you could create these files by hand, but you were very closely tied to the Visual Basic IDE for creating your application. In contrast, WinForms applications are written entirely in the programming language of your application, in this case Visual Basic. All properties and settings are directly accessible via the object hierarchy in WinForms and the .NET Framework as a whole. Therefore, you are no longer tied to a single IDE for developing WinForms applications. In fact, you are not tied to an IDE at all. You can create WinForms applications using only a text editor (if you don't mind a lot of typing). Generated CodeBecause the WinForms framework is completely accessible in standard code, anything generated by Visual Studio .NET (VS.NET) for you will be accessible in the code editing window. Older versions of Visual Basic hid a lot of generated information in the non-code portions of the .frm file. Now, VS.NET still hides it, but in a collapsed region in the code itself. Regions are simply a block of code that VS.NET can collapse down to a header and expand upon demand. Currently, the region is called "Windows Forms Designer generated code" and is collapsed by default whenever you open a form for editing. Starting Your ApplicationThe Project Properties dialog box has the same choices for starting your application as older versions. It has a drop-down list containing all forms in the application, plus Sub Main(). In older versions, Sub Main() had to live in a global .bas file, but now it can be a shared member of any class in the application (but there can be only one). If you choose one of the forms as the startup object, VS.NET actually creates a Shared Sub Main() on that form but does not create it in source code; rather, it is injected into the IL at build time. Adding Controls Dynamically (No Control Arrays)The days of implementing control arrays are over. Adding controls to a form in WinForms is easy. To add a new label, you might use the following code: Dim newlabel As Label = New Label() newlabel.Text = "This is a new label" newlabel.Top = 100 newlabel.Left = 100 Me.Controls.Add(newlabel) If you want to wire code to the new control's events, you must have existing methods that match the signature of the event. Then use the AddHandler function to add a delegate to the event's delegate list. For example: Private Sub Form_Load (ByVal sender As Object, ByVal e As EventArgs) AddHandler newlabel.Click, AddressOf Me.labelClick End Sub Private Sub labelClick(sender As Object, e As EventArgs) Dim clickedLabel As Label = CType(sender, Label) MsgBox(clickedLabel.Text) End Sub Input ValidationBoth Visual Basic .NET as well as all previous versions allow for a property to be set on many controls called Causes Validation. In both versions, this property enables events on those controls that fire when the control loses focus. In older versions, you had to create all your validation code ”and, more to the point, user notification code ”by hand. Programmers often created custom elapses to handle validation events. WinForms provides the ErrorProvider component. You still create event handlers for the validation events of your controls. Instead of creating your own user notification code, however, you use the ErrorProvider's SetError method. It takes two parameters: the control that is being validated , and the message to display to the user. The ErrorProvider component then handles the notification through a blinking alert tag and tooltip window that displays the warning message. See Chapter 3, Dialogs, for more information. Control PositioningWinForms provides much better positioning attributes for controls than earlier versions of Visual Basic. Before, you were limited strictly to the Left, Top, Width, and Height properties. If you wanted to have your forms react well when users resized them, you had to trap the form's various resize and redraw events and manually move or resize your controls. WinForms introduces two new properties for control layout:
These two properties, coupled with new controls such as the status bar and splitter controls, make it much easier to create forms that react reasonably to resizing. MenusThe venerable Menu Editor from Visual Basic 6.0 and earlier was a code-generating wizard that was fairly straightforward but not particularly usable. Its text-based representation and kludgy layout controls were bad enough, but the methodology for creating context menus (hidden menus in the main menu) was backward. WinForms provides two new components: MainMenu and ContextMenu. Most developers who are exposed to them for the first time are immediately wowed by their editors: You edit in place on the form in a very intuitive manner, creating new menus and submenus on-the-fly . The components provide other powerful features, too. For example, ContextMenu is a first-class component. This means that you can create context menus independent of a main menu and assign them to controls simply by setting the control's ContextMenu property. DialogsNo longer do you have to make reference to the external .DLL Microsoft Common Dialogs in order to present your users with a file or color picker dialog. WinForms ships with the following standard dialogs:
If none of these matches your need exactly, you can create your own class that derives from the one that comes closest and add the missing functionality yourself. See Chapter 3, Dialogs. Data GridsThe DataGrid control that ships with WinForms is much more powerful than the old Microsoft DataGrid control from Visual Basic 6.0. (For details, see Chapter 13: Data Binding and Data Grids.) Binding data is much easier and, thanks to the new ADO.NET library (System.Data), the binding is more efficient. Look-and-feel control has also been greatly improved, allowing you to design apps that don't look exactly like Excel 2.0. See Chapter 13, Data Binding and Data Grids. Advanced ControlsIn addition to the standard controls from earlier versions, WinForms ships with the following standard controls and components. In earlier versions, these controls required an external library, either Microsoft's or that of a third party. (Everything that ships with the Microsoft Windows Common Controls libraries is included with WinForms and is not listed here.)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 139
- ERP Systems Impact on Organizations
- ERP System Acquisition: A Process Model and Results From an Austrian Survey
- Enterprise Application Integration: New Solutions for a Solved Problem or a Challenging Research Field?
- Intrinsic and Contextual Data Quality: The Effect of Media and Personal Involvement
- Development of Interactive Web Sites to Enhance Police/Community Relations