[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using MODAL in IDL/v5.1 and above
- Subject: Using MODAL in IDL/v5.1 and above
- From: thompson(at)orpheus.nascom.nasa.gov (William Thompson)
- Date: 30 Nov 1998 21:26:04 GMT
- Newsgroups: comp.lang.idl-pvwave
- Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:12997
There's been some discussion lately about the changes to the MODAL keyword
between IDL/v4.0 and later versions of IDL. In particular, some widget
programs developed under IDL/v4.0 no longer worked in IDL/v5.1 and above. RSI
has given me a fix to xmanager.pro to correct this problem. Specifically, I
was told to comment out the line
WIDGET_CONTROL, ID, /MODAL
within the routine XMANAGER_EVLOOP_FAKE_MODAL in xmanager.pro. Commenting this
line out does appear to make our legacy software work in IDL/v5.1.1. I'm
told by RSI that the same fix will also work in IDL/v5.1 and IDL/v5.2.
The other issue that has been discussed is the additional restrictions that
have been placed on the new way of using the MODAL keyword within WIDGET_BASE,
as opposed to the old way of putting MODAL in the XMANAGER call. The
particular restriction that bit us was that, using the new syntax, modal
widgets cannot call nonmodal subwidgets. This didn't use to be the case. I
understand from RSI that they're still considering this issue. In the
meantime, they've suggested a way to get around these restrictions. The
procedure is as follows:
1. The MODAL keyword is not passed to either XMANAGER or WIDGET_BASE.
Instead, the actions of MODAL are emulated.
2. The "modal" widget desensitizes the calling widget.
3. Output from the "modal" widget is passed to the calling widget by setting a
widget value or user-value within the calling widget, rather than using
parameters in the procedure call. Part of this output is a parameter which
is initially set to zero. When the "modal" widget exits, it sets this
parameter to one. This is how the calling routine knows when the "modal"
widget is done.
4. The calling routine activates a timer widget to check if the modal widget
is still running. If it's done, then the calling widget resensitizes
itself, and continues processing.
This procedure is definitely more complicated than the old style, and requires
that the "modal" widget knows something about the internal workings of the
routine that called it. However, it does appear to work pretty well.
I'm not sure yet whether we'll try to modify our software along the above
lines, or continue to depend on the old style of passing MODAL to XMANAGER.
It'll probably depend on whether we would need to make the changes in 2 or 3
places, or in hundreds of places. Each procedure would need to be reviewed to
see if we can live with simply moving MODAL from XMANAGER to WIDGET_BASE, or
would need to do something like the above.
William Thompson