Tim Sneath

Musings of a Client Platform Guy

July, 2004

  • Tim Sneath

    Migrating from Windows Forms 1.x to Windows Forms 2.0

    • 6 Comments

    This entry starts by looking at the new features in Windows Forms 2.0, and then proceeds to describe the migration strategy for existing Windows Forms 1.0 applications that are to be migrated to .NET Framework 2.0.

    New Windows Forms Controls

    We've added some new controls to Whidbey:

    • MenuStrip / ToolStrip (for professional toolbars and menus) with advanced rendering capabilities to allow you to render for Office and also an extensibility model to allow you to supply your own custom rendering. Can add standard items.
    • StatusStrip: a control similar to the V1 StatusBar control but more panel-orientated.
    • DataGridView control: supersedes the old DataGrid control, and allows for easy binding to conventional data sources, web services or even business objects that support enumeration.
    • DataConnector (used to be called DataContainer): a helper for binding data to multiple controls.
    • SplitterContainer, a much improved version of the splitter control that automatically creates panels above/below or left/right of the splitter for ease of development. A lot of the issues with the old control (being invisible, auto-docking to the left hand side of a form) have been fixed.
    • WebBrowser: an in-built container for Internet Explorer
    • MaskedEdit: a masked-edit control somewhat like the old VB6 masked edit control but with greater flexibility and affinity to the TextBox control.
    • TableLayoutPanel and FlowLayoutPanel: matching the HTML model where sometimes you want to add controls in a forms model so that as your page resizes (or during localisation), the controls do the right thing and lay themselves out appropriately without manual intervention. Great for business forms.

    Other WinForms Improvements

    • Client configuration: XML-based model for saving the state of your application into the system. You can select any control that you want to be persisted, and bind it to an application setting. Select the control, navigate in the Property window to ApplicationSettings/PropertyBindings, and map the control to a setting. Unfortunately you still have to write the glue code to physically persist it (e.g. to a registry or a config file).
    • A BackgroundWorker component that provides asynchronous programming on a background thread with communication forward to the UI thread to update progress. This makes a difficult job much easier (see Chris Sells' canonical articles for advice on how to do this today in Windows Forms 1.0).
    • Improved printing API

    Deployment Improvements

    ClickOnce, a no-touch deployment and update mechanism for rich client applications. You can create a ClickOnce application through the Publish Wizard, which publishes an application to a URL. You can choose whether the application is available in online/offline modes or only whilst online. This has nothing to do with the functionality of the application, but it allows you to choose whether the shortcut to the application is in the start menu or as a URL. Publish Wizard allows you to sign the deployment manifest with a key, so that only the application publisher can make modifications to the application. The wizard copies all the files and the deployment manifest to a location (typically a URL). By default applications are set up to require full trust, but you can modify them to use a lower trust model. If necessary, the application prompts users for permissions to install the application if it requires a higher level of trust than would otherwise be granted to it.

    Designer Features

    • Smart Tasks: designed to make common tasks more straightforward - a little like Smart Tags in Office XP and 2003;
    • Designer layout assistance and usability: blue line means that the bottom is aligned; red line means that the text is aligned (useful for textboxes). Dotted lines between label and control when they are at the "standard" space as matches the UI guidelines. Also applies when you move a label to the edge of a form.
    • Hide initialize component: as well as partial classes to hide the code (Form1.Designer.cs), we also create a separate Program.cs file with the program stub (static void Main(), containing the Application.Run(new Form1()) invocation);
    • User control container: you can create a user control project and run it directly without having to create a test harness first.

    Migration

    The good news is that you can take any WinForms 1.x application and use it unchanged in the Whidbey environment using the existing controls. When you open a WinForms 1.x solution in Visual Studio 2005, the Visual Studio Conversion Wizard will kick in and offer to convert the project and solution files across to the new format, but it will leave the code completely intact. The old controls still exist, but are deprecated: for practical purposes, that means that they are not visible from the toolbox, but are available.

    The bad news is that if you want to migrate a WinForms 1.x application to utilise 2.0 functionality today, you'll have to do a little work by hand. There are some controls that are fairly easy to upgrade (e.g. StatusBar -> StatusStrip), but others that are much harder (e.g. DataGrid -> GridView). One approach to see the changes between the controls is to compare the output from the designer tools. For example, toolbar separators are treated as a special kind of button in the ToolBar control, but exist in their own right as separate controls in the ToolStrip. These minor changes should be fairly easy to fix with search and replace or a sed-style script, however.

    A Comparison of Old and New Controls

    Old New
    ToolBar ToolStrip
    MainMenu MenuStrip
    ContextMenu ContextMenuStrip
    StatusBar StatusStrip
    DataGrid DataGridView

    One thing to bear in mind is that the DataGridView does not include support for hierarchical tables, something the old DataGrid was good at doing.

  • Tim Sneath

    Integrating Corporate Data into Office with Information Bridge Framework

    • 0 Comments

    Office Information Bridge Framework (IBF) is a new solution that provides a standardised way for developers to integrate a company data-centric application into Office. IBF includes a means of specifying business entities and relationships between those entities, providing methods to retrieve the data, and creating a task pane for Office that provides a user interface for the functionality. For example, if you have a company HR system, you could use IBF to allow users to retrieve information from that system into a spreadsheet or Word document. IBF is a free download for anyone with an Office 2003 Professional Edition licence, from the following location:

    The architecture of an Information Bridge Framework solution:

    • The database: perhaps with a traditional web service façade
    • The metadata: glue code to abstract the data services
    • The solution components: UI for the application

    In IBF, you specify classes representing the business entities (customer, customers collection, order, orders collection), with appropriate attributes to control XML serialisation (e.g. [XmlRoot("Customer"), Namespace="urn-Northwind")]. You then provide GetX methods that retrieve a specific entity based on some known criteria (e.g. GetOrdersByOrderID). From Visual Studio, you can add entities to an Information Bridge Framework solution and map them to the underlying method calls for populating the information. Lastly, you can create a user interface that exposes the information and enables users to search for data based on some criteria.

    For more information, check out the technical white paper on MSDN.

  • Tim Sneath

    MSBuild: The New Build System for Visual Studio 2005 and Longhorn

    • 8 Comments

    MSBuild is the new build system in Visual Studio 2005. It has been built from the ground up in managed code, with scalability, performance and extensibility as core goals.

    When designing MSBuild, the development team had several different customer audiences that they kept in mind:

    • The Developer - someone who writes and compiles code regularly;
    • The Build Developer - someone who implements the processes for the build environment;
    • The Build Lab Tech - the person responsible for kicking off and managing the build process, making sure that builds don't break and fixing them as necessary. Note that this person may well not have Visual Studio on their machine.
    • The Build Lab Manager - who needs to track progress of the project and the build success/fail status. This individual would also probably not be a VS user.

    MSBuild is actually built into the operating system, rather than the development environment. This means you can build Visual Studio projects without VS installed; all you need is Windows (and .NET Framework 2.0 until Longhorn).

    MSBuild is driven by project files, which are created either by Visual Studio (automatically) or by hand by a developer. These are XML files that describe the build process elements (targets: build, clean, rebuild etc. that each contain constituent tasks) and inputs (items and properties). The project file is ultimately fed into the MSBuild engine, which in turn then generates the output.

    The XML input to MSBuild is of course strongly-typed; the schema ships with VS 2005 Beta 1 and is called msbuild.xsd: if you include the namespace definition in Visual Studio when editing with its inbuilt XML editor, you'll get full Intellisense when working with MSBuild project files.

    You can write the entire build process from scratch, if you like: here's a sample build project that compiles a C# application:

    <?xml version="1.0" encoding="utf-8" ?>
    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
       <PropertyGroup>
          <OutputPath>Bin\</OutputPath>
          <AssemblyName>MSBuildSample</AssemblyName>
       </PropertyGroup>
      
       <ItemGroup>
          <Compile Include="MSBuildSample.cs"></Compile>
          <Reference Include="System.dll"></Reference>
       </ItemGroup>
     
    <Target Name="Build">
       <MakeDir Directories="$(OutputPath)"
                Condition="!Exists('$(OutputPath)')" />
       <Csc Sources="@(Compile)"
            References="@(Reference)"
            OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
       </Target>
    </Project>

    To make the process simpler, MSBuild reuses elements of the build process through the use of .targets files, which define a compile target which is the override for any defaults. For example, Microsoft.CSharp.targets defines how to build C# applications with MSBuild; a similar file exists for J# and VB in the .NET Framework 2.0 directory (as specified in the LIBPATH environment variable).

  • Tim Sneath

    Building Advanced Reports with the Excel Add-in for SQL Server Analysis Services

    • 4 Comments

    The Excel add-in is one of two just released Business Intelligence solutions available for download:

    These are free of charge to licensed customers and include full documentation and PSS support.

    The aim for the Excel Add-in for Analysis Services is to provide a fuller reporting solution for OLAP cubes than is natively enabled in Excel PivotTables. You can use it to build a report structure with different grouping and segmentation options, and you can then fill that structure with data from an OLAP cube.

    Some nice features:

    • Drillthrough: the ability to see the constituent rows that make up an aggregation;
    • Suppress empty rows and columns (something not possible to do in an Excel PivotTable);
    • Elimination of selected dimension members from the report output;
    • Visual totals to only show aggregations of non-eliminated members;
    • Showing the unique name rather than the friendly name for all dimension members;
    • Showing server-defined formatting options (colour, font style, formatted value);
    • Ability to display MDX for the report as currently generated;
    • A free-from mode that allows a report to be generated using formulae rather than as a single monolithic block (like PivotTables are). This provides for a high level of customisation;
    • The ability to insert custom columns and rows in the middle of a report;
    • Leaf-level writeback for "what if" analysis.

    If you're looking for a spreadsheet-based client into Analysis Services and you're finding PivotTables slightly too structured, this add-in is well worth evaluating.

  • Tim Sneath

    Solving Business Problems with SQL Server 2005 Data Mining

    • 3 Comments

    Data Mining is about exploring your data, finding patterns and performing predictions. Where querying and analysis tells you what, data mining tells you why and how. In SQL Server 2005, data mining is made accessible and easy to use through an integrated user interface, cross-product integration and familiar, standard APIs. From the two algorithms that existed in SQL Server 2000, there are now a total of seven algorithms available out of the box, and it's possible to extend this further using an SDK.

    Data Organisation
    How can we organise data to provide the most pertinent information? OLAP provides fast queries with aggregations, but the hierarchies are schema-driven. That makes it hard to know what hierarchies are meaningful or provide actionable information. "Intelligent" OLAP provides self-organising cubes with data-driven hierarchies. You can achieve this with a data mining dimension: from a cube, you generate a mining model that is used in turn to create a new dimension.

    For example, the clustering algorithm takes the input data and attempts to segment it into groups. You could now rename those groups, before creating a data mining dimension and using them as dimension members for slicing data. Similarly, a decision trees algorithm could be used to generate a parent-child dimension. This enables us to determine (for example) which groups of customers are the most profitable, in a far more intelligent way than if we'd used OLAP alone without integrating data mining algorithms.

    Data Cleansing
    How do we clean data as we load it into the data warehouse? We can use DTS pipeline integration in combination with a DM clustering algorithm to separate out clean and bad data. This can help us detect spurious data members (for example, a parent younger than 10 years old).

    The steps are as follows:

    • Create a clustering model for the data you want to cleanse
    • Create a DTS project
    • Add a data source
    • Add a Mining Query Transform using the PredictCaseLikelihood() function
    • Do a conditional split based on the output.
Page 1 of 2 (10 items) 12