Hi Guys,

I wanted to give you guys a short overview on 6.3.x as I feel this version has been misunderstood :-).

The first thing that I must say is that we did a mistake with 6.3.x as we connected it to our commercial offering in such an early stage of it's release, although we did try to give you guys a real discount on our retail price so it will make sense buying an unstable version, but cutting back to the technological part which in these post is all I am looking to talk about, 6.3.x is a great version which had a few minor glitches which cause allot of bugs.

This is usually the problem with infrastructural development as a simple glitch can cause multiple bugs. We had allot of reports regarding problems with events not firing and application freezes, which definitely caused us to panic, as the last thing we want is such a version leaving the door. I personally opened an investigation to understand how come we released such a version ready to crucify the developer which caused this issue.

After a short investigation I understood that no crucifixion will be served here as this probably would not be avoided in terms of developer education. What actually happened is a collision of two concepts which are totally separated in their operation but had a connection between them that was never active until we fixed another issue. The two concepts are a mechanism to track the current active form and a mechanism to track the current active window, while these mechanisms sound related there cannot be any two mechanisms so different.

Tracking the active form provides Visual WebGui the ability to emulate WinForms windowing behaviors. For example, when one calls a ‘MessageBox.Show’ or ‘Form.ShowDialog’, one does have to state the owner form which is by default the active form. Allot of other WinForms behaviors are assisted by this ability.

Tracking the active window is a totally different story and serves only one purpose and it is to cope with Internet Explorers weird behaviors in conjunction with modal dialogs. Modal dialogs in Internet Explorer cause allot of undocumented issues, which by tracking the active window and using it for different tasks such as setTimeout or XMLHttpRequest, are solved. So as you might already guessed the active window in inline windows mode and non IE browsers is totally non relevant as the modal issue does not exist.

So returning back to the issue what actually happened is that a single line of code connecting these mechanisms caused tremendous damages in terms of stability. Suddenly operation expecting to work on a window got unexpected objects, those operation failed and where part of the core of Visual WebGui, so hideous bugs like click button not working so the day of light.

Now as I see it the real issue here is QA which as much as we did will never be as extensive as you guys do when you are trying it with all your different scenarios. In the previous development model which should be updated as I see it, we released an unstable version, which was sanity checked only and it took a month or two to be stabilized. As I see it is the same process which 6.3.x is going through, but 6.3.x was to be our first commercial version so you guys expected it to be perfect at the beginning. It is totally understandable and we anticipated it and invested allot of time in QA but as it turns out Visual WebGui is so big that we cannot QA our own framework without the open source development model.

So what we are thinking of doing and would be happy to get feedbacks from you guys, is to provide early releases of our upcoming versions which is equivalent to what is usually called ‘community technology preview’, this will enable you guys to check out our developments and to be prepared in an early stage for later versions and in some cases where you feel that the version is good enough to use it although we will not recommend that. With that we will create a beta testing program which will provide committed developers that will participate in actively checking Visual WebGui. We are still working on the details of this program and we will announce it as soon as we can, where as previews will be released starting very soon.

Regarding 6.3.3+ I feel that we got to a really good place with it and we are committed to have it stabilized in the next few weeks, it is definitely a priority so I encourage you to use it with the promise that every issue will be taken seriously and solved ASAP. Our version development policy is that anything that we broken in 6.3.x is scheduled to stability versions of 6.3.x and issues that were not previously working or where added in 6.3.x but require us to change infrastructure will be scheduled to 6.4.

I will announce our upcoming 6.4 (CTP 1) as soon as it is available for you guys to play with. 6.4 (CTP 1) will include the theme designer and control designer which as I see it should help you guys getting prepared to a new era of designing Visual WebGui applications and further more provide us with feedbacks regarding the needs that you have in terms of customizing the UI.

Cheers,
Guy

 Hi Alexando,

A Visual WebGui control is deivided into two, where as the "cs" part which is the server code is what the developer interacts or I can even reffer to it as the framework DOM which we implemented as WinForms. The client resources can be any resource which the client presnentation layer can use and those could be multiple resources for multiple needs.

Up untill 6.4 those resources where embeded in such a way that the namespace of the resource in the end assembly would be the control full type name + the resource name. There where standarts to how exactly those resources should be embeded and named and the VWG server new those standards. From 6.4 this is changing totally in terms that the resources are embeded in a resx file of a new class which is the Skin. Every control can have a skin class mapped to it and that skin class provides all the client needs he has.

The new skin class comes with a designer which provides point and click addition / removal / modifications of client resources. The skin is more powerfull than that as it allows to define properties (ie. BorderColor, BorderWidth...) which can be used both within the client resources and in the control.

So returning back to the control and its resources... Every control can generate metadata and is queried to generate metadata based on several factors. One factor might be that the control has been changed as for example if the label control text was changed the control needs to update its client representation of that change. There are multiple optimizations in this area which are using the fact that the client knows things and visa versa. Another factor can be redrawing of areas on the screen. 

The client side resources are responsible on how the control looks, behaves and most important, how the control interacts with the server in terms of sending events when something happens. The client side resources can either add an event to a queue on the client or adding an event and imidiatly causing the queue to be sent to the server. By queuing the events Visual WebGui optimizes the communication between the server and the client making the server based computing concept very scalable interms of chatiness.

I think that that the esiest way to grasp the concept is comparing it to how windows works interms of windows updating / events. The event queuing is there also in windows which there acts as a way to not forget actions and events while the computer cannot imidiatly process the event. For example clicking an icon while the computer is busy will queue that click in some cases and open the file later on (after you clicked it 10 times more... :-)). The other half of the analog is looking on how windows draws its UI and updates the UI. Windows defines what is called a window which every control / application recives one or more of them. Every window is responsible on updating a certain rectangle on the client and it does so by telling windows that its rectangle is dirty and should be redrawn.

The same happens in Visual WebGui where as in Visual WebGui instead of bitmaps redrawn every control "draws" metadata which is passed to the client for rendering. The control definies its self as dirty and one that requires redrawing and the Visual WebGui logic collects its metadata and sends it to the client. Here there are lots of optimizations also as Visual WebGui in lots of cases redraws a metadata diff update instead of the entire metadata.

This is the basic behavior of a Visual WebGui control but there are more concepts which are provided in addition which are gateways, client invocation and client client invocation. These concepts provide support for diffrent scenarios which the above concept is insufficient or expensive. 

Here is a short overview of the concepts and where you can find reference to usages:

• Gateways - provide a way to open a virtual page / or request handler from with in the context of the control or as a static one which simulates a normal virtual page. Static gateways are usually used when you need caching support for the request. Interms of usage the "chm help viewer" which allows to integrate help files into a Visual WebGui application serves its content using static gateway to enable caching of the content pages. The chart image drawing in the catalog sample is an example to a non static gateway which provides the control that uses it to dynamicly create a picture box content.
• Client invocation is a way to invoke client code from the server. For example when focusing a control there is no need to redraw it and event if we wanted redrawing a control will not set its focus. So when you call focus on a control a command is added to the response which invokes a client code that focuses the control on the client. There are couple of optimizations here as well as you can define the uniqness of the invocation, which is used for example to prevent multiple fucusing commands which are meaning less. When the response is returend only the last focused control should be focused.
• Client client invocation is a way to register actions on the client that do not postback to the server. For example the office richtexteditor uses this concept to implement the bold button which directly adds bold without returning back to the server. On the server the applications maps to controls together and defines what is invoked when this relation is called upon.

Ok... Looks like I have filled the page :-)

Hope that provides a better understanding of Visual WebGui...

Cheers,
Guy

Great information. Thanks, Guy.

Please, after release the 6.4 create an article about the implementation details of a simple control ( Label for example ).

(1) "...create a derived class from "Control"
(2) "...create a javascript named "yourcontrol.skin.js"
(3) "...create a derived class from "ControlController"
...etc...etc...

,
Alexnaldo Santos