Differences between Visual WebGui and Windows Forms

From Visual WebGui Wiki

Overview

The goal for Visual WebGui has always been to make it as compatible to Windows Forms as possible, taking into account few, but important web based limitations/concerns. This makes it possible to upgrade a Windows Forms application to Visual WebGui with Copy&Paste as you can see Forms-to-Web-Migrating-desktop-applications-part-1.aspx here, along with handling the differences which we will discuss in this article.

Important notice

The differences detailed in this article sum up all the differences we have found and documented here up to this point. Surely it does not document every possible difference.
If you have encountered any difference between Visual WebGui and Windows Forms that is not detailed in this article, please post the details in the Visual WebGui forums and we will add a section about this change in this article here.

Differences

Desktop versus Web

While Windows Forms application is a thick client desktop application, Visual WebGui is an thin or "empty client" application, where only the presentation is on the client browser and all the business logic runs on the webserver as your code behind code (server side code). This makes the Visual WebGui application a "secure by design" application.

This also means that there are different application templates used for creating the application, and there are different configuration settings that you need to be aware of. The most relevant difference is the introduction of the web.config file into your application.

Request / Response model

Visual WebGui is built upon ASP.NET technology and follows the rules and limitations set for that platform. Being an "empty client" application, your server is responsible of keeping track of the state of every control in you application, and your browser is responsible for rendering (drawing) those controls as per the server's instructions. Communications between the client and the server do not include business logic directly, rather the client sends notifications (requests or postbacks) to the server when a control's status has changed, the server processes the status change, including all the events that get raised, and finally sends back (response) orders on what the client needs to update or redraw as results of that change. Note here that the server does all the processing, none of it is actually performed on the client.

This is very different in Windows Forms application, where the application itself is performing both these tasks.

The Request / Response model does however increase the burden put on the little client side code (JavaScript) there is in Visual WebGui, as every single status change on a control that the server needs to know about to redraw the screen later, must be notified to the server. This is performed by raising client side events, which is a great concern to those creating Custom Controls for Visual WebGui.

It should be noted here that the Request / Response model of ASP.NET is mostly transparent to the developer in Visual WebGui, which is one of the buties of Visual WebGui. This is only written here for the purpose of understanding more of the contents of the article.

Server side code and Client side code

The most easy way to think of the differences here is to look at it in a very simplified manner and view the client just as a keyboard, mouse and monitor. When the user clicks on a button, the client side code has just enough client side code to notify the server (via a Request) that the button was clicked and then the server does all the processing, and when that is done, it sends information back to the client (Response) about what needs to be updated on the screen. And again, the client has just enough client side code to be able to perform those screen updates.

Filesystem access in code-behind code

As the code-behind code of your application is run at the server during request processing, with the client just showing the results, all access to the filesystem is made from the server. If you for instance open a file for reading in your code, that read request will come from the webserver, not the browser client. This is especially relevant when your code needs to access files that are on secured folder on the server or even on a folder that is not locally stored on the webserver. In that case, the file access request will be made using the credentials of the user running the webserver application pool, or if identity impersonation is being used, then the credentials of the user. This is also relevant when adjusting firewalls to allow such an access.

An exception to this rule are controls like OpenFileDialog, where local files on the client are being accessed to be uploaded to the server from the client machine.
In MS Windows Forms using the OpenFileDialog control, you view files that are on the server and load them back to the server.
In Visual WebGui, the OpenFileDialog is completely a client-side component. This means that the when in Visual WebGui the OpenFileDialog allows you to view files on the client and send files from the client to the server.

External communication in code-behind code

The same rules apply here, as for filesystem access. Consuming webservices in code-behind code, XML2RPC communication etc. will have all the requests coming from the server, not the client.

External communication in client-side code

Not all communication in your application is initiated from the server. References to images (and other gateway references) will become requests for those images when rendered on the client, and then a request will be made from the client to the server hosting the images or the requested resource. Same is true for other Url references in the UI of your application, like Url in HtmlBox etc. They will be requested by the client and from the client when your form is rendered on the client.

Dialog Forms

Dialog Forms in Windows Forms halt execution of your program while waiting for client response, even if it's just pressing the OK button. As you can see on the Request / Response model above, this is much different in Visual WebGui. When running a Visual WebGui serverside code showing a dialog form, the server simply "notes" that it must have a Dialog Form drawn on the client when it sends it's response to the client, and then continues executing the next line after the ShowDialog() command, not waiting for any response from the user.

Using Dialog Forms that must wait for user's input must be specially handled in Visual WebGui and you can see more information here.

Dialog Forms lookalikes

In some programming languages in Windows Forms you have MsgBox() and InputBox() functions. These functions to show dialogs are not Web aware and can not be used in Visual WebGui. It may at first look like they are working for you when you run your application on your desktop in Visual Studio Development envirionment, but that is simply not the case. Those functions require to be connected to an UI thread to be able to display the dialog, and in the case when you are running this within Visual Studio, they are, and there fore they do show. When deploying to a Web server, they will be run under a thread that does not have any connection to the UI on the server, and even if they did, they would be showing up on the server, not on the client. Remember again that the client is just a dummy monitor.

Images and Graphics

In Windows Forms the System.Drawing.Image represents a bitmap image of some sort, and is used for all Image-like control properties in Windows Forms, like PictureBox.Image.

In Visual WebGui, those image-like properties are not of type System.Drawing.Image but of some of the ResourceHandle types, see more on Images and Gateways.

The major difference being that when you assign a bitmap to an Image property in Windows Forms, you are actually assigning the bitmap contents itself to that property, while when you assign a ResourceHandle to an Image property in Visual WebGui, you are assigning a special kind of web address to the Image property. When the Image is rendered in the browser, the browser performs a request to the server for the contents of the image, and then the browser handles displaying of the actual bitmap. That browser request for the image is handled and served by your application by a Gateway.

This difference is probably by far the cause for the most common mistake made by Visual WebGui developers when displaying images.

Dynamic images not on the Resources folders

Static images on the Resources folder of your applications are handled (served) by the builtin gateways (ImageResourceHandle, IconResourceHandle etc.). For dynamic images you need a little different approach, compared to Windows Forms. You can see more about dynamic images in the Images article.

Custom drawing of controls

In Windows Forms you can override the OnPaint method and practially draw the control using GDI API. In Visual WebGui this approach is not supported and the OnPaint method is not implemented. You can however use the Theme and Control designer to customise the controls skin by replacing images or edit the XSLT of the controls, which actually renders the HTML of the control on the browser, and thereby gain full control over it's appearance. In addition, since you are writing a web application, using the Theme and Control designer, you can override and change the client behaviors (by editing the JavaScript resources of the control or the common ones) and you can also change the control's style (by editing the CSS files of the control or the common ones).

Events

Critical Events

There are 2 seperate sets of events occurring in a Visual WebGui application. The first set is the events occurring on the client itself (JavaScript events) and then there are those occurring in your server-side code running the code you assign to your controls in your designer.

Remember that the main purpose of the client side events is notifying the server of any changes that occur on client side controls (in your browser) so the server can react.

For optimization purposes, Visual WebGui classifies events as critical and non-critical based on if the server needs to be notified about them as soon as possible or not. Take for instance a CheckBox which you add to your form. If you don't register any valuechanged event (like CheckedChanged etc.), the server doesn't have to know about that event right away. It's enough for the server to know about the value change the next time some critical event occurs. This is what Visual WebGui does for you automatically as an optimization in communications between client and server. When some critical event occurs, the server gets all the events that occurred, both critical and non-critical, in the same order they occurred and reacts to all of them in that sequence.

If you do register a valuechange event on that CheckBox in our last example, that will make that event critical, and the server will be notified about the valuechange right away. And as above, along with any onther non-critical events in the same sequence the events occurred.

Some controls, like the DataGridView, have special properties (DataGridView.IsSelectionChangeCritical) to tell the client if it should treat some subset of it's events as critical or not.

OnEvent overrides for non-critical events

Under the hood inside the server-side code for the controls, the OnEvent methods (like OnFormClosing etc.) are responsible for invoking the event handlers that have been registered for the corresponding event. It deserves special mention here that if an event is determined to be non-Critial, the onEvent method on class level will not be invoked because of this same optimization.

In other words, if you override, for example, the OnFormClosing method of the Form class, your override code will not be invoked on closing of the Form, unless you make sure the FormClosing event is made a critical event. The most simple way to make that event critical, is simply registering an (empty) event handler for that event.

Queued Events

In some cases, you may want to react to changes in control status, but you don't necessarily need to know right at the moment the event occurs. For that purpose Visual WebGui introduces the "Queued" version of many of it's events. Continuing with the CheckBox example above, the CheckedChanged event has a queued version named CheckedChangedQueued. Those events are raised in the exact same situation, only difference being if the server gets to know of them right away, or the next time some critical event is raised.

Those queued events are available to you for optimizing the communication between the client and your server.

Mouse events

In Windows Forms there is a more rich set of Mouse related events than there is in Visual WebGui. While thinking of this, you have to remember that Visual WebGui is a Client / Server implementation, and the client must notify the server of any event raised that the server must know about. The Windows Forms Mouse events MouseDown, MouseUp, MouseEnter, MouseLeave, MouseHoover and MouseMove are for this reason not implemented in Visual WebGui as implementing them would degrade the performance of you application dramatically because of how rapidly they do fire.

Keypress events

The keyPress events (KeyDown, KeyPress and KeyUp) are implemented in VisualWebGui, but as with the rapid firing Mouse events these should be used with caution as they will degrade the performance of your app considerably, if not used sparingly. Registering an event handler to any of those events makes that event critical, which means a request will be sent to the server for every keystroke you make.

To help with the optimization of your application, Visual WebGui implements a KeyFilter property where you can name the keys you want to handle. Visual WebGui will react, and only send KeyPress events for the keys you have in your KeyFilter, not for others. By default KeyFilter is All, which means it will fire the event for every keystroke.

Drag and Drop events

For the same reason as the mouse events, many of the Drag and Drop events have also not been implemented in Visual WebGui, only making the DragDrop event available to Visual WebGui developers. This means that Drag and Drop is done a little differently in Visual WebGui, than in Windows Forms.

As the result of this, the Visual WebGui implementation of Drag and Drop is a little different than Windows Forms. Basically it requires you to register a DragDrop event handler on the target object and that event will then be fired from the target object when the dropping occurs. A simple example of drag and drop in Visual WebGui can be found here.

Scroll event

For this same performance reason, the Scroll event, which can be found on scrollable controls in Windows Forms, is not implemented on Visual WebGui controls.

Individual controls

TextBox

The "Validated" and "Validating" events are not fired when Textbox focus is lost only when the text is changed, which is different from Windows Forms behaviour. Please see this issue here for more info.

Global or Static variables

In Windows Forms you are used to have Global or Static variables global for the single instance of the application being run at any given time, meaning that if you load two instances of the application on the same desktop, you will have two sets of the Global variables.

In Visual WebGui this is very different. Global variables are global for all instances of the application for all users. There will only be one single memory space occupied by any single global variable, no matter how many users or how many instances.

See more on alternatives in Storage Scopes,

Enhanced Visual WebGui features/API

One of Visual WebGui's major goals, is to be as Windows Forms compatible as possible/practical. This does not mean that there are no improvements over the Windows Forms implementation and the reality is actually quite the opposite. Many of the Visual WebGui controls have had major improvements over the Windows Forms implementation.

ListView

The most major enhancements made for the ListView control over the Windows Forms standard are listed below, and the links will take you to a showcase application discussing those enhancements in more detail:

The enhancement to allow you to place any control within a ListViewSubitem, deserves a special mention here, as it makes the ListView a very powerful and expandable control in Visual WebGui. As, for example, TextBox, Panel, Form, ListView and DataGridView all derive from Control, this enhancement will allow you to put any of them within a ListViewSubitem cell.

MenuItem

In Visual WebGui, the EventArgs parameter to the MenuClick event handler carries information about which MenuItem was selected. We can use this fact to simplify the code and create only one procedure for handling MenuClick of a whole MainMenu system. This can not be done in Windows Forms, as the EventArgs does not carry this information. An example code can be found here.

Temporarily not or partly supported features/API

In the most recent version of Visual WebGui (currently 6.4.0Beta1c), some controls or control APIs are only partially or not yet supported. Most of the missing implementation is planned for the next major release of Visual WebGui, version 7, which will focus on missing implementations for controls that exist in Windows Forms 2.0.

MDI Form support

MDI is partly supported in current version of the framework. We roughly estimate that about 40% of the Windows Forms 2.0 implementation is already supported in Visual WebGui, with much improvement planned in version 7.

ToolStrip, MenuStrip, StatusStrip

These Windows Forms 2.0 controls are missing in current version of Visual WebGui, but the functionality is mostly covered with the Windows Forms version 1.1 implementation using MainMenu, ToolBar and StatusBar controls. With proper design, the Windows Forms 2.0 controls are almost completely replacable with the Windows Forms 1.1 controls currently implemented in Visual WebGui. Implementation of the Windows Forms 2.0 controls is planned for version 7 of Visual WebGui.

ErrorProvider

Some of the Windows Forms API for the ErrorProvider is missing in Visual WebGui, planned to be implemented in version 7 of Visual WebGui.

ToolTip

Some of the Windows Forms API for the ToolTip control is missing in Visual WebGui, planned to be implemented in version 7 of Visual WebGui.

DataGridView

The DataGridView is one of the most complex controls in Visual WebGui and although a major effort has been put into that control in the last few versions of Visual WebGui, there is still more to come, with customizable columns planned for version 7 of Visual WebGui.

GroupBox

The GroupBox does not render line-breaks that are added to the Text property of the control. Please view this issue here for reference.

References

Forum Threads

Sample applications

Data-centric Windows Forms to Web showcase

Other references