| While the DataSet class is not new for Visual Studio, the DataSet element in the Toolbox is new. The DataSet Toolbox element launches yet another wizardin this case, it gives you two fundamentally different ways to build or reference a DataSet, as shown in Figure 7.5. Figure 7.5. Adding a DataSet to a Form using the DataSet Toolbox element. 
In either case, this technique is used to add an XSD-based, strongly typed DataSet or untyped System.Data.DataSet DataSet instance to a Form or custom component without generating bound UI elements. Once the DataSet is added to your form, it becomes part of the Form code scope, so it appears in other dialogs that permit easier binding (as you'll see later in this chapter). A Typed DataSet: In this case, the DataSet Toolbox element generates a named instance of a specified DataSet already in your project. The Name drop-down list enumerates the existing XSD strongly typed DataSet classes already created in your project. The documentation says you can simply enter a name that will be available at runtime. Apparently, this was not hooked uponly existing XSD DataSet classes were accepted. I see this element is useful when you want to place a reference of your XSD STD on the Form but don't want any UI elements generated, as happens when you drag and drop selected TableAdapter objects from the Data Source window. When you click "OK" on the Add DataSet dialog, Visual Studio adds an icon to the Tool Tray at the bottom of the Form's design-time UI. This element includes a "smart tag" (as shown in Figure 7.6) that can be used to launch the DataSet Designer. No, you can't drag this element to the Form. Figure 7.6. The Tool Tray DataSet icon supports a smart tag.  An untyped DataSet: In this case, Visual Studio simply creates a new named instance of System.Data.DataSet. The default name is "DataSet1," but you can rename it via the properties dialog. It won't be of much use unless you write the code to populate the schema and data. Binding to an untyped DataSet at design time is problematic, at best. Until Visual Studio can determine the schema (by running the query or inspecting the SELECT), it won't be able to help much with data binding. That's why there's so much emphasis on strongly typed DataSet classes. I can't see a practical use for this unless you need a named DataSet to bind to other controls at design timeexpecting to populate the other Properties at runtime.
|
