A tutorial of Windom step by step ... The redraw function of a window
Programming guideline of WinDom

Create a window

Let's start this tutorial with a very basic example: create and handle a window in the WinDom environment. Look at this first example:

     #include <windom.h>

     void main( void) {
          /* window descriptor */
          WINDOW *win;

          /* WinDom initialisation */
          ApplInit();

          /* Create a window and keep its descriptor */
          win = WindCreate( NAME|MOVER|CLOSER,
                                app.x, app.y, app.w, app.h);

          /* Open the window */
          WindOpen( win, app.x, app.y, app.x+app.w/2, app.y+app.h/2);

          /* Handle the GEM events */
          while( wglb.first)
               EvntWindom( MU_MESAG);

          /* Terminate Windom session */
          ApplExit();
     }
As we said in the introduction, WinDom programming is very similar to GEM programming. Actually, it is possible to use WinDom exactly like GEM but it is not the most efficient way. The only difference between GEM and WinDom in this example is the GEM events returned by EvntWindom() (the equivalent of evnt_multi()) are not handled! In fact, events are implicitly handled by EvntWindom() by using standards functions given by WindCreate() to the window win. The variable win is the window descriptor.

For example, WindCreate() gives to the new window the function WindClear() (this function draws a white bar inside the window) as redraw event function. It means that when EvntWindom() catches a redraw event (ie the GEM message WM_REDRAW), it will use the function WindClear() to refresh the window's workspace. Obviously, the first step in WinDom programming is to write a new redraw function for the new window created by WindCreate().

What's about the event handling? In this example, the while() instruction uses the WinDom global variable wglb which gives information about windows in WinDom. The field wglb.first points to the descriptor of the first window created by WindCreate(). If this variable is NULL, then there is no more window. And why there is no window? Because the window previously opened has been closed by the user (by cliking the closer widget of the window). When you click on the closer widget, the AES screen manager sends a WM_CLOSED message to our application. Of course, our window own a standard function handling this message. This function sends a special message to the screen manager (the WM_DESTROY message). This message is not a standard GEM message but a special WinDom message. In WinDom, we make the distinction beetween close a window and destroy a window. WM_DESTROY means that the window and its data have to be destroyed. The standard function attributed by WindCreate() to the message WM_DESTROY closes and deletes the window using the WindClose() and WindDelete() WinDom functions. The destroy function is usually the second function (after the redraw function) written by the developper.