... bug¹

For those IDL programmers among you here are the gory details of this bug. Widget events are the programming mechanism used to notify filter widgets that a new Domain Dataset is available, and the mechanism used to ``push'' the Apply Button. Unfortunately, IDL does not guarantee that widget events created with calls to widget_control, SEND_EVENT=... will be handled in the order they are created. Thus, in some situations the Apply Button event will be handled (a new WDS computed) before the new DDS data has been sent to the filter widgets, leading to a corrupted Working Dataset. Any subsequent manual refiltering will be done correctly. This bug was fixed by adding a call to widget_event after creating events announcing the new DDS and before creating the event to the Apply Button.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... TARA.²

This is only necessary if you want Event Browser to use a printer different from your default printer. For example, if you set the environment variable LPDEST to a double-sided printer in your .cshrc file, you may want to force Event Browser to use a single-sided printer.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.