Making an already running Windows Forms desktop data application available on the Web or deploy it on the Cloud, has in the past been a very resource intensive and tedious task. You have very few options and all of them require that you rewrite most, if not all, of the user interface logic. Migrating to Visual WebGui provides you with a framework that, with very few exceptions, is code compatible with the Windows Forms API so your migration process becomes a simple copy of the source code and a few global Find/Replace operations on the source, and you have an almost ready Visual WebGui Web application with no need to rewrite the user interface.

In addition, Visual WebGui enhances some of it's controls compared to Windows Forms, which makes your converted Visual WebGui even more powerful and flexible than your original Windows Forms application. A classic example of those enhancements can be found in the converted sample applicaton and later in this article, where the ListView control has been enhanced with a dialog for reordering of columns, a dialog for selective sorting on multiple listview columns, automatic internal paging and relaying the sorting operation to the database layer to minimize the load on the web server.

This article will walk you through the major tasks required for conversion of Windows Forms application to Visual WebGui application, adding some enhancements along the way that are available in Visual WebGui and not in Windows Forms.

General overview of the process, as well as general overview of differences between Windows Forms applications and Visual WebGui applications can be found in the references section, where you will also find information about conversion of third party controls and thread safety considerations.

The sample applications require a database connection to an updated NorthWind database. The updates are minor, and are only in the form of a few added SQL views. For convenence, the updated database can be downloaded below. If you already have installed the NorthWind database on your server, you can also download an SQL script that will create the necessary SQL views.

Visual WebGui applications by default require that application images and icons, that do not come from a database, reside on a folder named Resources, directly on the root of the virtual folder of the application. Also, by default, application images and icons are kept seperate on folders named Resources\Images and Resources\Icons.

When preparing for a conversion of Windows Forms application to Visual WebGui application, you will have to collect all your images and icons that are stored in your Windows Forms application into Resources\Images and Resources\Icons folders. Subfolders within those folders are of course allowed, and smart naming of subfolders that reflect the original placement within the Windows Forms application might ease the conversion considerably.

For the purpose of this sample, this step has already been performed, and all the (non-database) applications images and icons can be found on those folders within both of the sample code projects.

You start the conversion process by creating a Visual WebGui application.

This is a simple file based copy of all the *.cs and *.resx files from the Windows Forms application folder to the Visual WebGui application folder. You should leave the Program.cs file behind though, as it is not used in Visual WebGui. You should include the Resources folder in your copy, so all your application images and icons will be included.

All over your Windows Forms project, there are references to System.Windows.Forms. These references include both C# "using" statements, as well as other namespace refererences to that namespace. To handle the majority of the conversion cases within your Visual WebGui application, it is safe to Find/Replace over your entire Visual WebGui project and serch for "System.Windows.Forms" and replace it with "Gizmox.WebGUI.Forms".

As required by the codechanges, one or more of the following additional C# "using" statements were added to the source code:

The major difference here is image and resource handling. In Windows Forms you use the FromFile function to retrieve the image bitmap directly from from the local disk from where the Windows Forms application is running, and assign it to the Image property of the PictureBox. In Visual WebGui, the image is stored within the virtual folder of the applicaton on the webserver, and we use an ImageResourceHandle (a builtin Gateway) to reference the image. The "value", assigned to PictureBox.Image in Visual WebGui, is a (gateway) reference to an image whose actual contents will be retrieved by the browser when the page is rendered.

Another difference here is that Windows Forms uses the LinkLabel.URL property for it's links, while Visual WebGui uses LinkLabel.Text for the same purpose.

Finally we use the WGConst class to retrieve and display the version number of the Visual WebGui framework.

This class serves the purpose of retrieving images from a database. The Windows Forms version reads the image data from the database, writes it to a temporary file, and then uses the Image.FromImage() static method to retrieve the bitmap and return.

As mentioned before, Visual WebGui uses images in a fundamentally different way, by using gateway reference. For this purpose we use the DatabaseResourceHandle class in Visual WebGui. The most notable difference is the overridden WriteContent method. The way it works is like with other images in Visual WebGui. You assign a gateway reference to an Image property and when the browser renders the page, it will request the image contents. The purpose of the overridden DatabaseResourceHandle.WriteContent method is to retrieve the correct image from the database and write it's contents to the response outputstream, when the browser requests it.

The actual use of the CategoryPictureResourceHandle class is very similar in both versions of the application, while the actual retrieving of the database image is quite different. In Windows Forms you assign the actual bitmap to the Image property and the image is retrieved at the time the server-side (code-behind) code is run, while in Visual WebGui, only a reference is created in the code-behind code and the actual image contents are fetched when the browser renders the page, with the help of CategotyPictureResourceHandle.WriteContent method.

Same difference as before, applies to images in ListViewSubItem. The Windows Forms application uses an ImageList for the ListView images, for optimization purposes so that only one copy of each image will need to be retrieved from disk, although it would be used more than once in the ListView. For Visual WebGui, there wouldn't be much difference, as all images, ImageList or not, are references and retrieved when the browser renders the page, so we chose to use simple image reference without an ImageList. The GetIcon function is just a helper function for building the reference and returns an IconResourceHandle, thereby (by default) referencing icons from the Resources\Icons folder within the virtual folder of the application.

Building the graph bitmap is identical in both applications. As before, a Windows Forms application assigns the bitmap directly to the PictureBox.Image property, while Visual WebGui creates a reference to a gateway, and the browser will request the bitmap when it renders the page.

This intoduces the use of Visual WebGuigateway within the form itself, which will generate the bitmap and write it to the response strean upon request from the browser via the overridden ProcessGatewayRequest method:

In Visual WebGui we have various enhancements over Windows Forms implementation and we use a few of those enhancements in the demo application.

In Windows Forms we need one MenuClick event handler for each MenuItem, as we can't distinguish between MenuItems by the EventArgs type only. In Visual WebGui we can use the same approach, or we can use the fact that the argument to the MenuClick event handler is of MenuItemEventArgs type, which makes enables us to move all the MenuItem event processing inside of one single MenuClick event handling procedure.

In Visual WebGui we have a ListViewColumnOptions dialog form that we can use to enable ListView columns reordering and selection of columns to display in the ListView. This greatly enhances the richness of the ListView functionality with just just two extra lines of code. This functionality does not exist in Window Forms.

In Visual WebGui we have a ListViewSortingOptions dialog form that we can use to enable sorting options in the ListView, even on multiple columns you select. This yet more enhances the richness of the ListView functionality with just two extra lines of code. This functionality does not exist in Windows Forms.

In Visual WebGui we have an internal capability of paging as an integral part of the ListView. Paging in a ListView is an optimization method that prevents huge mounts of data to be loaded in the client's browser. The ListView (either fully automatic or manually as in the sample application) "pages" the data and only sends the records for the currently active page in the ListView to the client's browser, thus only a small portion of the total number of records are actually sent to the browser at a time. Using fully automatic ListView internal paging does however mean that the whole dataset will be loaded on the server side on the webserver. Best practice, to minimize resource usage on the web server, is to have implement manual paging where only the data for the currently active ListView page is loaded from the database to the webserver and then to the client.

This capability does not exist in Windows Forms.

In Visual WebGui we can get the sort order from the Sort (ColumnClick) event and then run the sorting on the Database, loading the result set again in order to sort the entire set of records, not just the displayed ones.

The samples assume you have the NorthWind database installed on a local SQLEXPRESS database server and the database name is NorthWind. If your setup is different, you will need to change database connection strings to reflect your actual environment. The database connection string can be found in 3 places in each project and you will have to update all of them (CategoryPictureResourceHandle.cs, frmItemDetails.cs, ExtendedListView.cs). Search for the string "Data Source" (without the quotes) in the projects and make your adjustments to the connection string(s).

You might also want to change the temporary path used to store images in the Windows Forms application. Open CategoryPictureResourceHandle.cs, view FromImage method and change the value for the str variable, if current setting does not fit your needs.

• Original Windows Forms application to be migrated
• Migrated Visual WebGui application (C# and VB.NET in VS2050 and VS2008)
• Online demo of migrated Visual WebGui application

The database used in the sample code is the original NorthWind sample database with a few SQL views added for convenience. The NorthWind database, as used in the sample, is included for convenience. If you already have

• NorthWind database used by the sample code
• SQL script to run on original NorthWind database to create the SQL views used by the sample code

The article has walked you through the major steps involved in migrating a Windows Forms application to Visual WebGui. It discusses the steps needed to prepare for the migration and how you can simplify some of the tasks. The article then discusses the major differences between Windows Forms and Visual WebGui that we faced while migrating this particular application, and provides solutions and suggestions for how to handle them. Finally it discusses a few of the many improvements Visual WebGui implements on it's controls compared to Windows Forms.

• Windows Forms to Web - Migrating Desktop Applications
• Differences between Visual WebGui and Windows Forms
• Forms-application-to-the-Web-using-Visual-WebGui.aspx How to migrate a Windows Forms application to the Web using Visual WebGui