You might be interested in two additional tools that work with Visual Studio. Even better, both are free. The first is a tool for creating your own Visual Basic snippets. As discussed, snippets can be powerful tools when you need to replicate relatively small but commonly used blocks of code that will be customized. While Visual Studio ships with several such snippets, Microsoft probably hasn't included the snippet you want the most.
This is where the first tool comes in: a Snippet Editor for Visual Basic code snippets. This editor doesn't actually live within Visual Studio; it just updates the snippet files you want to use from Visual Studio. Behind the scenes, snippets are actually XML files with embedded text that represents the code used in the snippet. What the Snippet Editor does is read that XML and interpret all of the embedded logic related to things such as replacement blocks. This tool makes it possible for Visual Basic developers to create custom snippets without worrying about the XML formatting details. It is available from MSDN at http://msdn2 .microsoft.com/en-us/vbasic/ms789085.aspx.
The second tool is a true add-in to Visual Basic. When Microsoft was announcing features for .NET 2.0, it was apparent that Visual Basic and C# had different feature lists. Over time, the developers in each community started to better understand what these features represented, and in many cases demanded their inclusion. One such feature was native support in C# for refactoring, the capability to modify a variable name — for example, to take "i" and call it "loopControl" so that it's more readable. Modifying code to improve structure, performance, and maintainability is referred to generically as refactoring.
Traditionally, such changes might make the code more maintainable but it often entailed more risk than reward; as a result they seldom were made. The problem, of course, is that a human tends to miss that one remaining reference to the old version of that method or variable name. More important, it was a time-consuming task to find all of the correct references. Fortunately, the compiler knows where these are, and that's the idea behind automated refactoring: You tell Visual Studio what you want to change and it goes through your code and makes all the necessary changes, using the same rules the compiler uses to compile your code.
This is a great maintenance tool; unfortunately, by the time most Visual Basic developers understood what it implied, it was too late for the Visual Basic team to implement a solution in Visual Studio 2005. However, the team did do better than just say, "So sad, too bad." They found a commercial product that actually had more features than what the C# team was developing from scratch. Then they bought a license for every Visual Studio developer, allowing free download of the tool. This solution worked so well for everyone involved that they chose to continue it in Visual Studio 2008 and Visual Studio 2010. With refactoring, you can quickly clean up gnarly, hard-to-read code and turn it into well-structured logic that's much more maintainable. The free version of the refactoring tool is available at www.devexpress .com/Products/NET/IDETools/VBRefactor/.
To start enhancing the application, you are going to use the control Toolbox. Close the Form1.designer.vb file and switch your display to the Forml.vb [Design] tab. The Toolbox window is available whenever a form is in Design view. By default, the Toolbox, shown in Figure 1-23, is docked to the left side of Visual Studio as a tab. When you click this tab, the control window expands, and you can drag controls onto your form. Alternatively, if you have closed the Toolbox tab, you can go to the View menu and select Toolbox.
If you haven't set up the Toolbox to be permanently visible, it will slide out of the way and disappear whenever focus is moved away from it. This helps maximize the available screen real estate. If you don't like this feature and want the Toolbox to be permanently visible, just click the pushpin icon on the Toolbox's title bar.
The Toolbox contains literally dozens of standard controls, which are categorized so it's easier to find them. Figure 1-23 shows the result of dragging a Button control from the Toolbox and depositing it on the form: a new button displaying the text "Buttonl." Adding another button would trigger the default naming and text of "Button2."
Before customizing the first control added to this form, take a closer look at the Visual Studio Toolbox. The tools are broken out by category, but this list of categories isn't static. Visual Studio 2010 Standard and above editions enable you to create your own custom controls. When you create such controls, the IDE will — after they have been compiled — automatically add them to the display when you are working in the same solution as the controls. These would be local references to controls that become available within the current solution.
Additionally, depending on whether you are working on a Web or a Windows Forms application, your list of controls in the Toolbox will vary. Windows Forms has a set of controls that leverages the power of the Windows operating system. Web applications, conversely, tend to have controls oriented to working in a disconnected environment.
It's also possible to have third-party controls in your environment. Such controls can be registered with Visual Studio and are then displayed within every project you work on. When controls are added to the Toolbox they typically appear in their own custom categories so that they are grouped together and therefore easy to find.
Return to the button you've dragged onto the form; it's ready to go in all respects. However, Visual Studio has no way of knowing how you want to customize it. Start by going to the Properties window and changing the Text property to Run Code. You can then change the button's (Name) property to ButtonTest. Having made these changes, double-click the button in the display view. Double-clicking tells Visual Studio that you want to add an event handler to this control, and by default Visual Studio adds an On_Click event handler for buttons. The IDE then shifts the display to the Code view so that you can customize this handler (Figure 1-24 shows the code for this event handler being edited).
In 35 Col 31 Ch 31
Although the event handler can be added through the designer, it's also possible to add event handlers from Code view. After you double-click the button, Visual Studio will transfer you to Code view and display your new event handler. Notice that in Code view there are drop-down lists on the top of the edit window. The boxes indicate the current object on the left — in this case, your new button — and the current method on the right — in this case, the click event handler. You can add new handlers for other events on your button or form using these drop-down lists.
The drop-down list on the left side contains the objects for which event handlers can be added. The dropdown list on the right side contains all the events for the selected object. For now, you have created a new handler for your button's click event, so let's look at customizing the code associated with this event.
Was this article helpful?