GUI (Graphic User Interface) are screens generated with all of the GeneXus generators for a Windows environment.

GUI and WEB visualization
The base language of web pages (HTML) is not strictly designed as in the GUI screens generated with GeneXus. This is why the visualization of the application may differ depending on the way the code is interpreted by the engine that is being used.
In particular, as far as the graphic design is concerned, it is impossible to reach an accuracy level as 'exact' as in GUI environments. In HTML environments there is a difference between what is seen during development, and what is seen upon production. Actually, once in production, the design's visualization varies depending on the engine (Internet Explorer, Netscape, etc.).
Thus, concerning this particular issue, the recommendation is not to take this web environment as a GUI environment and not to make any attempt to have it perform as such. Keep in mind that they are different environments with different characteristics.

Events handling
There used to be three types of events in GUI environments:
- Events that do not work on any record
- Events associated to a line
- Events associated to a group identified with &op='X'

1- Events without lines: a typical example of this are the close and add buttons, which behave in the same way, regardless of the line that has been selected. In Web environments they can be left as is  -which works fine- or be replaced by:

a- A text control with a link loaded in the Start event
b- An image with the click property or an associated event

2- Events associated to one line: For instance, detail buttons such as modify or eliminate. Upon migration into the web environment, the client's engine cannot figure out which line has been selected. It is no longer possible to select a line as we did in the GUI environment. (The upcoming GeneXus Olimar version -which is currently in the beta test process includes elements to sort this out). In order to replace them, remember that:

a- Events calling another WebPanel, or WebTRN may be replaced by a new column, with text or an image with a link loaded in the load event of that particular sub-file. For example, a "detail"button may be replaced by a column with the text "detail", and link &detail.Link =link (HDetail, parameters) loaded in the load event of this sub-file.

b- Events calling a procedure or executing some code may be replaced by a "click"event in combobox and chekbox variables. This way, we can obtain an even in which to write our code. For instance, taking several events to a single combobox ("Advanced").

Event &Advanced.Click
Do case
case &Advanced ='A' //'Something ')
call(PSomething, ATTKey)
case &Advanced ='M' //Modify
call(TTransaction, ATTKey,'UPD')
&.

The case is used for selecting the event. This way any code can be executed as was the case in an ordinary event in the past.

3- Events on more than one line with a 'For Each line': The 'For Each line' command works fine. It is only necessary to add what sub-file you wish to work on. For example, a figure can be added instead of a button and a figure.click event.

Event 'Add'
&
For each line In main

This way, the image has a property that associates an event (add) to the click made on this image.

Parameters
In a web environment, it is impossible to know where a click was made in order to get to a page. That is why even though the return option returns to the previous page, the value of the variables used in the previous page is unknown. There are several options for saving 'environment' variables:

a- Saving a cookie: This is easy, but the number of cookies is limited and varies from client to client. In the example from the start event, a cookie is recovered with the values of the parameters.

&Param = GetCookie( 'MiCookie' )
&Travel =val(substr( &Param ,1,8))
&Date=Ctod(Substr( &Param ,9,8))
&

and in the main sub-file's refresh' eventis saved

&Param =str(&Travel,8,0) + &Date
&OkCook =SetCookie( 'MiCookie' , &Param )

Here, all the parameters are saved in a single cookie in order to minimize the quantity of cookies.

c- Passing those variables which are necessary as parameters to all the WebPanels. Encryption of such parameters is recommended in order to hide its logic.
d- Having a structure with a session identifier in the database.

Style and Webcomponents
The fact that styles do not exist in a Web environment is a big disadvantage when facing WorkPanels. However, the WebComponents make up for that. A Webcompoent is a webpanel object, different from the rest in that it may be added into another webpanel. This makes code reuse easier; the same feature may be 'imported' to a webpanel as many times as necessary without having to repeat the code. This tool is a major difference, and gives this environment an advantage over GUI which will make up for the loss of styles. (Note: The GeneXus Olimar version will include a feature called "themes" which will make it possible to define a form's control properties, and then an object based on that topic).

Dynamic generation
Due to the fact that in the GUI environment the screen was completely generated all at once, rather than dynamically, this change is likely to lead to some mistakes.

For instance, if there were a &quantity variable showing the number of records displayed in the sub-file, for the Web environment we would include an &quantity=0 in the refresh event, and a &quantity += 1in the load event. Although this change is correct, if the variable is placed over the sub-file, it will be always displayed with a "0" value regardless the quantity of records that are read. This is due to the fact that the part of the screen shown before loading the sub-file is generated prior to the sub-file processing, when the variable was "0".  Then, upon executing the code which loads the sub-file, the variable adopts the correct value. However, it is too late, since our event will have already been generated with the wrong value.

Interaction with the user
Once the procedure has been started, there cannot be graphic interaction. This happens because in a web environment there cannot be procedural interruptions in order to request information from the client. For simulating an event's confirmation, a new event can be added so that the link, which will actually execute the process, will become visible or enabled.  For instance, if there is an "Adjust Exit" combo box in a webpanel, and it has the following code in the combo box click event:

case &Advanced='S' // 'Adjust Exit)
ConfirmOption.Visible =1
&MyVariable.visible=1

Here, the image which actually has the adjust-upon-exit code will become visible.

Event 'Option'
call(PMyProcess , &MyVariable)
&MyVariable.visible=0
ConfirmOption.Visible =0
Endevent

That is how we will transmit the idea that a confirmation has been requested before adjusting the exit, although the procedure is actually called in a different event.

Webpanel calls
A CALL (or LINK as a command) to a Web Panel is "asynchronical": it will show the Web Panel upon finalization. For example, the execution of two CALLs to Web Panels in an event does not cause both of them to be executed; it only makes the last call to take "control"of the engine once the caller code is finished.
That is the reason why the selection-list type of programming is not used. For instance, in a "Select Register" event, which used to call a WKP WSRegister, and then a PRC PGRegister that saved the license plate that had been selected, now in a web environment it should be the selection list the one doing everything that is required.

call(HSRegister&Save, ATTKey)

In this case, instead of calling a WSRegister, which will retrieve the selected license plate for a PRC to save it in the base, it is sent by the line identifier so that the selection list will save the plate. As a result, selection lists cannot be reused and a different object is necessary each time a license plate has to be selected.

Security and access
In a GUI environment, in order to avoid access to a workpanel when the user did not have a permit, a control was set in an event and as a result the restricted workpanel could be called or not.

If &security='S'
Call(WDetail, FacClient)
Else
Msg("You don't have permissions to see the client")
Endif

Even though the link may be enabled or disabled in the load event - not to give it the option unless it is appropriate-  it is also necessary to make sure the user does not write the URL address directly. In a web environment, the web page address can be written directly and using the desired parameters. This may be controlled by encrypting the parameters and by having some control in the query's start event.

Event load
If &security='S'
&detail.link=link(hdetail, FacClient)
endif

Petroglifo: http://www.concepto.com.uy/petrocsharp  (Web Site in Spanish)

For more information on this:
GUI-to-Web application conversion
GUI-WEB comparison