| Associating color-table with widget application [message #8754] |
Wed, 23 April 1997 00:00  |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
The problem is simple: in a widget application, I want the widget to
load its own color-table whenever the cursor is "in" the application,
and load a pre-existing color-table when the cursor is "out" of the
application. Sounds easy right? Please tell me it is...what keyword
did I miss this time?
I tried using tracking events, but you get color-flashing whenever
you leave one widget and enter another, even if you enable tracking
events for ALL widgets. If you enable tracking events for only the
TLB, you lose your colors whenever you move into, say, a slider
widget which adjust a plot which you really need to see in the
correct colors...
Then I saw the KBRD_FOCUS_EVENTS keyword to the WIDGET_BASE()
function, and I thought I was quite clever. But of course you
lose your colors again when, say, you press a slider widget that
adjusts a plot which you really need to see in the correct colors...
This seems so basic. It's easy to do for, say, a draw widget. But
how do you do it for an entire widget heirarchy? RTFM's welcome!
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 2200
La Jolla, CA 92037
[ UCSD Mail Code 0949 ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
| Re: Associating color-table with widget application [message #8806 is a reply to message #8754] |
Mon, 28 April 1997 00:00  |
Phil Williams
Messages: 78
Registered: April 1996
|
Member |
|
|
David Fanning wrote:
>
> David Foster <foster@bial1.ucsd.edu> writes:
>
>> The problem is simple: in a widget application, I want the widget to
>> load its own color-table whenever the cursor is "in" the application,
>> and load a pre-existing color-table when the cursor is "out" of the
>> application. Sounds easy right? Please tell me it is...what keyword
>> did I miss this time?
>>
>> I tried using tracking events, but you get color-flashing whenever
>> you leave one widget and enter another, even if you enable tracking
>> events for ALL widgets. If you enable tracking events for only the
>> TLB, you lose your colors whenever you move into, say, a slider
>> widget which adjust a plot which you really need to see in the
>> correct colors...
>
> Hi David. I think you are right to be thinking about color "protection",
> especially as we move into IDL 5 and an accessable command line
> while widget programs are running. I've been giving this idea
> a lot of thought, too. (See the new example programs that I
> put I my web page overnight.)
>
> But I guess I don't fully understand the problem you are having.
> I don't, for example, seem to have problems when I move into
> a slider. Perhaps because I have been taking a different
> approach. My idea is that each widget program ought to
> "know" its own colors, but be unconcerned with everyone
> else's colors. This way, when you enter a widget (via
> tracking on the TLB or a draw widget [although tracking
> on TLBs seems to be broken in the IDL 5 beta]) the widget
> program can restore its colors. This is what I mean by
> color protection.
>
> You necessarily have color flashing as you move from
> one widget to another, since the various widgets
> are using the same color indices, but I don't find it
> annoying in the slightest. In fact, it is exactly what
> I want!
>
> Anyway, perhaps an example of what you are stuggling
> with will help us find a solution.
>
> Cheers!
This is exactly what I do in my XDISPLAY program. I have one app that I
can have as many as 10 XDISPLAYs opened and each has it's own color
table. As the mouse moves into one XDISPLAY the LUT is updated w/ that
colors and all the olthers follow.
If you need to have more than one LUT at a time then you need to split
the color table. XDISPLAY can also do this (on a limited basis) by using
"greyscale/color" mode.
see http://www.irc.chmcc.org/idl/xdisplay.html for more info.
Phil
--
/*********************************************************** ********/
Phil Williams, Ph.D.
Research Instructor
Children's Hospital Medical Center "One man gathers what
Imaging Research Center another man spills..."
3333 Burnet Ave. -The Grateful Dead
Cincinnati, OH 45229
email: williams@irc.chmcc.org
URL: http://scuttle.chmcc.org/~williams/
/*********************************************************** ********/
|
|
|
|
| Re: Associating color-table with widget application [message #8844 is a reply to message #8754] |
Thu, 24 April 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
David Foster <foster@bial1.ucsd.edu> writes:
> The problem is simple: in a widget application, I want the widget to
> load its own color-table whenever the cursor is "in" the application,
> and load a pre-existing color-table when the cursor is "out" of the
> application. Sounds easy right? Please tell me it is...what keyword
> did I miss this time?
>
> I tried using tracking events, but you get color-flashing whenever
> you leave one widget and enter another, even if you enable tracking
> events for ALL widgets. If you enable tracking events for only the
> TLB, you lose your colors whenever you move into, say, a slider
> widget which adjust a plot which you really need to see in the
> correct colors...
Hi David. I think you are right to be thinking about color "protection",
especially as we move into IDL 5 and an accessable command line
while widget programs are running. I've been giving this idea
a lot of thought, too. (See the new example programs that I
put I my web page overnight.)
But I guess I don't fully understand the problem you are having.
I don't, for example, seem to have problems when I move into
a slider. Perhaps because I have been taking a different
approach. My idea is that each widget program ought to
"know" its own colors, but be unconcerned with everyone
else's colors. This way, when you enter a widget (via
tracking on the TLB or a draw widget [although tracking
on TLBs seems to be broken in the IDL 5 beta]) the widget
program can restore its colors. This is what I mean by
color protection.
You necessarily have color flashing as you move from
one widget to another, since the various widgets
are using the same color indices, but I don't find it
annoying in the slightest. In fact, it is exactly what
I want!
Anyway, perhaps an example of what you are stuggling
with will help us find a solution.
Cheers!
David
----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
|
|
|
|
| Re: Associating color-table with widget application [message #8846 is a reply to message #8754] |
Thu, 24 April 1997 00:00 |
tim
Messages: 9
Registered: July 1994
|
Junior Member |
|
|
I think I understand what you're describing, but forgive me if
I don't!
You have one application window that contains a number of other
widgets (buttons, etc.) It's when you move the mouse into
and out of this window (the application) that you want to change
colour table, but at present it's changing as you move around
WITHIN this application. Is that correct?
have you tried creating a large base widget for the whole application
in which all the otehr widgets sit and turn on event_tracking
for this base widget, and turn it off for all the others. (I use
event_tracking in a similar way for a context sensitive help,
and I group a set of widgets in this way and connect the help to
their base widget instead of each individual widget so that I
can desribe them all in one go).
I don't know. This sounds like something you probably tried.
But then it might just be one of those obvious DUH! things :)
Tim
David Foster (foster@bial1.ucsd.edu) wrote:
: The problem is simple: in a widget application, I want the widget to
: load its own color-table whenever the cursor is "in" the application,
: and load a pre-existing color-table when the cursor is "out" of the
: application. Sounds easy right? Please tell me it is...what keyword
: did I miss this time?
: I tried using tracking events, but you get color-flashing whenever
: you leave one widget and enter another, even if you enable tracking
: events for ALL widgets. If you enable tracking events for only the
: TLB, you lose your colors whenever you move into, say, a slider
: widget which adjust a plot which you really need to see in the
: correct colors...
: Then I saw the KBRD_FOCUS_EVENTS keyword to the WIDGET_BASE()
: function, and I thought I was quite clever. But of course you
: lose your colors again when, say, you press a slider widget that
: adjusts a plot which you really need to see in the correct colors...
: This seems so basic. It's easy to do for, say, a draw widget. But
: how do you do it for an entire widget heirarchy? RTFM's welcome!
: 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 2200
: La Jolla, CA 92037
: [ UCSD Mail Code 0949 ]
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
