home *** CD-ROM | disk | FTP | other *** search
- <head>
- <title="...forever...">
- <font=monaco10.fnt>
- <font=newy36.fnt>
- <font=time24.fnt>
- <image=back.raw w=256 h=256 t=-1>
- <buf=2213>
- <bgcolor=-1>
- <background=0>
- <link_color=253>
- <module=console.mod>
- <pal=back.pal>
- colors:
- 251 - black
- </head>
- <body>
- <frame x=0 y=0 w=640 h=2213 b=-1 c=-1>
-
-
- .: GEM in one pill :.
- -----------------------------
- 7) Dialog boxes
- ------------------
- Dialog boxes are an interactive formular in which the user can input text and
- make selections with mouse pointer.
- Dialog boxes are 'modal' and it means that while dialog box is displayed, other
- screen and window control functions are suspended (you have no access to
- menubar for example) until you close the dialog.
- In most cases, the visual look of the dialog boxes is described in RSC file of
- your application.
- To put the dialog box on screen you have to:
- a) load rsc file with rsrc_load()
- b) find the address of our dialog in resource tree with
- rsrc_gaddr(R_TREE,MY_DIALOG,&tree)
- c) after finding the address you can display it:
-
- form_center() sets the position of the dialog box on the screen. It calculates
- top-left position to center the dialog box on the screen i copies the OB_X and
- OB_Y fields to ROOT object of the tree. It calculates also the rectangle in
- which dialog will be displayed and saves the coordinates to variables
- xdial,ydial,wdial,hdial.
- WARNING: form_center() is causing trouble, the rectangle returned in xdial,
- ydial,wdial,hdial is the same size like the oridinary dialog box. When we will
- add the OUTLINED attribute to the dialog, form_center() adds 3 pixel margin to
- returned rectangle and the screen underneath the dialog isn't correctly
- refreshed. Attributes like SHADOWED and OUTSIDE aren't automatically handled
- and you have to take it into account when writing code.
-
- After that we call form_dial() with 0 as a parameter (it reserves the screen
- for our dialog).
-
- Next goes form_dial() with 1 as a parameter. It creates an effect called "zoom
- box" (fully optional).
-
- Then we perform objc_draw() to draw the dialog on the screen. As a parameters
- we put the address of of the rsc tree, address of the beginning of the object
- (our dialog), the depth of the objects to draw and rectangle assigned to the
- dialog box.
- Generally speaking dialog boxes and their parts are ALWAYS on the beginning of
- the ROOT or object nr. 0. When you want to draw only a part of the dialog box,
- adjust only the clipping rectangle, not the object number, so the background
- will be drawn correctly.
-
- Function form_do() hands out the overall control to AES, which animates the
- dialog (). The adress of the dialog tree is passed as a parameter. Second
- parameter is a number of editable object, on which the text cursor will be
- placed. If you don't expect any editable fields then simply pass 0.
-
- After that form_do() returns the object number which was pressed, in most cases
- is the BUTTON object with EXIT and SELECTABLE flags setted. Activating of
- DEFAULT attribute tells to the system that the specified object is
- automatically chosen by CR (carriage return) or RETURN or ENTER in more human
- language.
- ATTENTION PLEASE! If the most significant bit is setted, then it means that
- EXIT object had TOUCHEXIT attribute and was chosen with the double click of the
- mouse.(it's possible to mask it)
-
- Next the for_do() does reverse "zoom box". It zooms the dialog from the
- specified location to the rectangle (x,y,w,h).
-
- After that form_dial() tells that the dialog box is ready and the parts of the
- screen area are considered as "dirtied" and have to be redrawn. GEM sends the
- redraw messages to all the damaged windows and redraws all that is needed.
-
- The calling of form_dial(3) redraws the area, which is 2 pixel higher and wider
- than area that you specified! This little thing isn't harmful at all, and it
- redraws all the shadows if they exist. If shadows dosn't exist then who cares?
- The calling of form_dial(3) isn't only used as a redrawing routine for dialog
- boxes. With this call you can redraw any screen area you want. The merit is
- that, the redrawed area doesn't have to lay wholly in the window like in redraw
- message handling functions. Of course the drawback is that this treatment is
- much slower, because AES has to decide what parts of display need to be
- redrawn.
-
- CLEANING UP
- The very last step is clearing of the SELECTED flag on the chosen object. If
- you don't do this , the object will be inverted after next displaying of dialog
- box. The clearing of the flag should be perfored with objc_change(), but this
- is not very good in sense of performance, because we don't have to redraw the
- whole object.
-
- SUMMARY
- Handling of the dialog consists of 3 steps:
- - initialisation (loading of the rsc file)
- - presentation of the dialog box
- - cleaning up
-
- With more complicated dialog boxes, the standard handling process is getting
- complicated a bit. The initialisation will have for example the initial setting
- of the flags and strings and the cleaning up phase will check what the user has
- done.
-
- MORE BUTTONS..........
- Oridinary dialog boxes contain only one EXIT button as a active object. They
- aren't much better than simple windows with warnings. Now we want to increase
- complexity by adding the buttons without exit. They are setted by SELECTABLE
- attribute on the BUTTON object. The chosen object will be changing the state
- from selected (highlightened) to not selected each time the user will click on
- it. The SELECTABLE attribute can also be used on objects of another type than
- button. Owning of this kind of button forces us to solve the problem tied with
- initialisation of buttons before showing the dialog, checking and deselecting
- them. As activating and deactivating of the button is connected with it's flag,
- we have to test the flag during the initialisation and if true make a
- sel_objc(tree,BTOBJ) call. This will highlight the button after the first draw
- of the dialog. BTOBJ contains the name of the button defined in RSC file. As
- the button starts deselected you don't have to do anything if your flag
- variable isn't true.
-
- After sucessful drawing of the dialog box we have to check the state of the
- object. We can mask out the OB_STATE field. After that we deselect all the
- dialog buttons before exiting the dialog box function.
-
- DIALOGS WITH MULTIPLE CHOICES
- The next application of the button are buttons with multiple choices. This type
- of objects are radio buttons. Selecting of one button from the whole set
- deselects all the other. Each member of the button set has to be the sibling of
- the same parent. What the hell is that you ask?
- To create such structure you have to put the BOX object to the dialog box in
- RSC editor, check if all the buttons will fit inside the box, add them one at
- time into the box. By nesting the buttons inside the box we force the radio
- buttons to became the members of the one parent. Each buttons must have an
- attribute SELECTABLE and RADIO BUTTON activated. Additionally you can hide the
- box by setting the box frame to 0, but do not flatten it! (whatever it means).
-
- As each of the radio buttons represents another option. After the dialog box
- inintialisation we have to check which option is activated first and select
- adequate button. Instructions if-then-else should be constucted in the way, so
- the only one button can be selected at once. While exiting you have to check
- every button and set the internal variables. Once again the if-then-else should
- be performed to make sure that only one button is activated.
-
-
- -- - --- -- -------------------------------------------------------------------
- CHOSNECK 4th appearance contact us:
- done by the dream survivors greymsb@poczta.fm
- ----------------------------------------------------------------- -- - --------
- </frame>
- </body>
-
-