| widget_list in IDL 5.1 [message #11934] |
Tue, 09 June 1998 00:00  |
Jonathan Rogness
Messages: 7
Registered: April 1997
|
Junior Member |
|
|
I'm building an interface to routines that I've written over the past
couple of years, and after we upgraded to IDL 5.1 earlier this week I
discovered I can now use the MULTIPLE keyword to WIDGET_LIST, which
allows users to select more than one item in the list.
Here's my problem: how can I tell which items have been selected? The
index field of the Event structure is still a single number, not an
array. Even if many items are selected, Event.Index is just the index
of the /first/ selected item. Do I have to call widget_control? Out of
curiosity I tried using the get_value keyword to widget_control, but it
looks like that's still not an option with list widgets.
My apologies if this is answered in the documentation. I only have
printed manuals through version 5.0, and our online HyperHelp is causing
my window manager to crash. (Hopefully RSI will fix that relatively
soon.) I can see the documentation for WIDGET_LIST, which doesn't
answer my question, but if I try to look up WIDGET_CONTROL, I end up
having to restart my X-Server because of the crash.
Thanks for any help -
Jon
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12028 is a reply to message #11934] |
Mon, 15 June 1998 00:00  |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
jared gottlieb wrote:
>
> A variation on the theme:
>
> I'm working with the /NON-EXCLUSIVE variant of button-groups (IDL 5.1, DEC
> UNIX platform). When the user selects one of the buttons an event select
> occurs and I can get a 0/1 map of which buttons are currently selected.
> When the user toggles (de-selects) the button, there doesn't seem to be an
> event. There is an /NO_RELEASE for the call to CW_BGROUP that in the
> manual promises an event only when a button is selected. The opposite does
> not appear to be the default, that is a '/RELEASE'. Any ideas for a direct
> solution?
Just remove the /NO_RELEASE keyword. You are telling IDL to send
events only when buttons are selected, so no event is generated
when a button is released. This keyword is useful when you have
exclusive buttons, when you only want an event from the button
that was selected, and not from the one that was *unselected*.
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12036 is a reply to message #11934] |
Mon, 15 June 1998 00:00 |
NOSPAM.jared
Messages: 1
Registered: June 1998
|
Junior Member |
|
|
A variation on the theme:
I'm working with the /NON-EXCLUSIVE variant of button-groups (IDL 5.1, DEC
UNIX platform). When the user selects one of the buttons an event select
occurs and I can get a 0/1 map of which buttons are currently selected.
When the user toggles (de-selects) the button, there doesn't seem to be an
event. There is an /NO_RELEASE for the call to CW_BGROUP that in the
manual promises an event only when a button is selected. The opposite does
not appear to be the default, that is a '/RELEASE'. Any ideas for a direct
solution?
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12050 is a reply to message #11934] |
Fri, 12 June 1998 00:00 |
J.D. Smith
Messages: 214
Registered: August 1996
|
Senior Member |
|
|
David Fanning wrote:
>
> J.D. Smith (jdsmith@astrosun.tn.cornell.edu) writes in
> response to Jonathan Rogness' question about multiple
> list widgets:
>
>> Just use:
>>
>> list=widget_info(list_widget,/LIST_SELECT)
>>
>> This will always return the current selected , or -1 if none selected.
>
> Yes, this certainly tells you which widget is selected, but
> the problem I have is when to take action in a multiple list
> selection, since I get an event in my event handler *every*
> time a selection is made.
>
> It seems I have several choices:
>
> (1) Act on every event, which I normally don't like to do
> at all.
>
> (2) Guess when the user is finished, which results (believe me!)
> in a lousy user interface.
>
> (3) Write a compound widget with the list widget and an OK
> button to let me know when the user *really* wants me to
> respond to the selection event. But this is just like the
> multiple selection widget I hacked up before the MULTIPLE
> keyword was available.
>
> What do some of the rest of you do? If we can get some
> kind of consensus, I'll write an article about it for my
> web page.
I don't see how you could act on multiple selection events, David, since the
selection is never *over*. I can add a member to the selection list using
Control-Click (Apple-Click for Mac Users), or remove one from the selection too.
Since the user can take as many steps as he/she wants to define the multiple
selection, I don't understand your issue. The only obvious place for multiple
selection events would be when shift-selecting a range of list items, but how do we
know the user wouldn't rather Control-click them individually?
The only workable solution I see is number 3, or some variant. I.e. for multiple
widget lists, don't take any action which depends on the selected list when you
receive widget_list event. (Except maybe for double-clicks.)
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-4083
206 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12064 is a reply to message #11934] |
Thu, 11 June 1998 00:00 |
menakkis
Messages: 37
Registered: June 1998
|
Member |
|
|
davidf@dfanning.com (David Fanning) wrote:
<...>
> What do some of the rest of you do? If we can get some
> kind of consensus, I'll write an article about it for my
> web page.
I haven't got round to using multiple list widgets yet, but when I do I think
I'll treat them rather like I do text and field widgets. With these sorts of
widgets I prefer not to rely on hooking decisive actions onto the widget
events for all except the simplest interfaces where the inter-dependencies
between the controls are clear to the user. I have seen the occasional
program that does various recalcs and updates several other widgets' states
while you're busy typing into a numeric field, say. These interfaces
sometimes look slick but on the other hand they're sometimes unclear. Anyway
this is more trouble than I'm prepared to go through most of the time. An
interface that has "fiddly" widgets like these will typically include one or
more other widgets (like an "OK" button or something) with a more decisive
event. I think it's usually adequate to capture (and check, etc) the current
states of all the fiddly widgets at the time that one of these decisive
events occurs. I usually try to avoid interface designs where there are
strong constraints involving the current states of "fiddly" widgets. e.g.,
Say you have a button that must only be active if there's more than 1 item
selected in a list (in the same panel). In this case I'd probably move the
list off to a dialog of its own (with OK/Cancel buttons).
Peter Mason
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12065 is a reply to message #11934] |
Wed, 10 June 1998 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Peter Mason (menakkis@my-dejanews.com) writes:
> An interface that has "fiddly" widgets like these
> will typically include one or more other widgets
> (like an "OK" button or something) with a more decisive
> event.
Have you trademarked the term "fiddly widget"? I would like
to use it in my next book and I am prepared to pay handsomely
for the privilege. :-)
Cheers,
David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: widget_list in IDL 5.1 [message #12069 is a reply to message #11934] |
Wed, 10 June 1998 00:00 |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
David Fanning wrote:
>
> It seems I have several choices:
>
> (1) Act on every event, which I normally don't like to do
> at all.
>
> (2) Guess when the user is finished, which results (believe me!)
> in a lousy user interface.
>
> (3) Write a compound widget with the list widget and an OK
> button to let me know when the user *really* wants me to
> respond to the selection event. But this is just like the
> multiple selection widget I hacked up before the MULTIPLE
> keyword was available.
>
> What do some of the rest of you do? If we can get some
> kind of consensus, I'll write an article about it for my
> web page.
>
What I do is probably a similar hack to what everyone else has to
do to get this to work. I just have an array of flags that tell me
which items are currently selected, and each time I process a
WIDGET_LIST event I update the flags (to either select or unselect
items). In the list itself, selected items are marked with '*'.
In our applications it's always the case that the user has to
press some "Start" button or the like to act on the selected items,
so knowing when the user is finished selecting items isn't really
an issue (yet!).
I was very disappointed after I learned that the event from a
list widget only returns one item when multiple items are selected.
Duh!
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
