Dr. T.C. Zhao (zhao@bragg.phys.uwm.edu)
Mon, 9 Dec 1996 22:00:23 -0600

To subscribers of the xforms list from "Dr. T.C. Zhao" <zhao@bragg.phys.uwm.edu> :

From: Petasis Gewrgios <ph1566@rea.edu.physics.uch.gr>

>int handle_free1(FL_OBJECT *obj,int event,FL_Coord mx,FL_Coord my,
int key,void *xev)
> int dif,value,saturation,y,R=125,G=255,B=200;
> int tmp_R,tmp_G,tmp_B,k,ww=13,wh=10;
> switch (event)
> {
> case FL_DRAW: /* Redraw Object */
> fl_freeze_form(test_form->test);
/* fl_deactivate_form(test_form->test);*/

Yeap, this is where things go wrong. When you receive
FL_DRAW event, many of the book-keeping stuff has been
taken care of by the event dispatcher.
All you need to do (and it is assumed so) is draw. Any other
high-level routines (freeze_form is one of them,
fl_set_object_label, color, lalign font are others) would cause
problems ( e.g., fl_set_object_color would cause infinate recursion).

When you think about it, fl_freeze_form does not make any sense
here (maybe the document is partly to blame). If you draw
10 lines, no matter what the 10 lines has to be drawn and
fl_freeze_form does not and can not reduce the drawings.
fl_freeze_form is useful when you have to change multiple
attributes of an object, where each change will trigger
a redraw:

fl_set_object_label(ob, label) /* redraws the object */
fl_set_object_lstyle(ob, FL_BOLD_STYLE) /* redraws the object */

To suppress the multiple redraws, you enclose these code
between freeze_form and unfreeze_form.

I will check the document to make sure fl_freeze_form is docuemnted

To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see