On Fri, 15 Aug 1997, Dr. T.C. Zhao wrote:
> To subscribers of the xforms list from "Dr. T.C. Zhao" <zhao@bragg.phys.uwm.edu> :
>
> from Mark Edward Johnston <M.E.Johnston@damtp.cam.ac.uk> :
>
> >As far as I can tell, the problems seem to be associated with
> >calls to fl_hide_object() on an input object. One thing I noticed
> >was that the callback associated with that object gets called
> >during the call to fl_hide_object(). This seems odd, no ?
>
> Depending how you look at it. Hiding an input object or a form
> with input object on it is considered an input focus change
> and in most cases, invoking the callback is the correct
> behavior. Perhaps the manual should make this clear.
Well if it's documented, then yes, we can deal with it. For example,
in the program I gave, if I move the call to fl_hide_object(input) before
the call to fl_delete_object(slider), it works, as the slider is still
alive when the fl_hide_object(input) call calls the callback.
However, I'm not sure I agree this behaviour is The Right Thing.
It means that fl_hide_object(FL_OBJECT *) performs a
significantly different function depending upon the type of FL_OBJECT,
which is confusing, and is likely to lead to bugs, as mentioned by a
previous poster.
Before you read on - a quick question:
Is it essential to call fl_hide_object() before fl_delete_object() ?
If not, I can remove the fl_hide_object calls, which would solve my
problems.
I guess I am talking about using fl_hide_object() as a precursor to
fl_delete_object() and fl_free_object(), and so am thinking about the
desired behaviour of fl_hide_object() in the context of getting rid of an
object. Those using fl_hide_object() in other contexts (eg. a temporary
hide) may see the calling of the callback as desirable. In the former
context though, it makes for more work. For example, I have a form
with a number of inputs on it, and when the value of one of the variables
set by these inputs changes, the values of variables associated with
other inputs can change, so I call a function updateFromParameterValues()
at the end of each input callback:
void dsParameterPanelXF::updateFromParameterValues()
{
for (int j = 0; j < updateables.size(); ++j)
updateables[j]->updateFromParameterValue();
}
When I delete the form, I used to go:
for (int j = 0; j < updateables.size(); ++j) delete updateables[j];
but if the callbacks get called upon deletion (the destructor of the
updateable objects contains a call to fl_hide_object(input)), then
already-deleted objects get the updateFromParameterValue() call.
Thus I have to do the trickier:
while (updateables.size() > 0) {
ParameterInput *tmp = updateables.back();
updateables.pop_back();
delete tmp;
}
Also, I noticed that when hiding/deleting two input objects in a row,
the callback was only invoked on the second input object.
Is the callback always called by fl_hide_object(), or only sometimes ?
(this happened in the middle of a large program, so I don't have a short
example - removing the fl_hide_object() calls seemed to fix it).
Any thoughts/opinions ?
Mark J.
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/