[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Comm... err, alternative?
Pavel Romashkin wrote:
> David Fanning wrote:
> > The more relevant question, it seems to me, is why
> > in the world would you care? Multiple windows on the
> > display are going to be mixed up by the user anyway.
> > Why try to go to any effort to order them?
> My idea was, if a user creates several plot windows during an ad-hoc
> session, then he can overplot from command line to any one of them by
> just bringing it to the foreground. I am beginning to think that a
> common block is appropriate here, because I see no other way to link an
> existing widget with command-line executed code.
Maybe there's another way. The following is from the IDL 5.3 online help
"The XREGISTERED function returns True if the widget named as its
argument is currently registered with the XMANAGER as an exclusive
widget. Otherwise the routine returns false. If the named widget is
registered, XREGISTERED returns the number of instances of that name in
the list maintained by XMANAGER. The registered widget is brought to the
front of the desktop unless the NOSHOW keyword is set."
"Note - XREGISTERED checks for Name in a COMMON block created by
XMANAGER. The stored name is case-sensitive."
The common block in question is named 'MANAGED' (not such a good name,
COMMON managed, ids, $ ; IDs of widgets being managed
names, $ ; Names of widgets being managed
modalList ; List of active modal widgets
If your application is named 'XPLOT' (i.e. the name that was passed to
XMANAGER), then if N instances of the widget exist, there should be N
entries in NAMES with the value 'XPLOT', and N corresponding entries in
IDS. Thus you could get to the identifiers of active widgets without
having to create your own common block. Of course, this relies on the
internals of XMANAGER: it would be better if XREGISTERED returned an
array of identifiers for the requested widget names.
If you choose to go ahead and create your own COMMON block or
user-defined system variable, then at least you have things under your
control, and you are not depending on the XMANAGER implementation.