| Re: Using Comm... err, alternative? [message #21180] |
Thu, 17 August 2000 16:34 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"David Fanning" <davidf@dfanning.com> wrote in message
news:MPG.1406144ab7dbf879989bdc@news.frii.com...
>
> ...But have you checked your
> ftp logs? Pavel and I (and Ben, of course, it goes without
> saying) are the only ones who have downloaded the darn things. :-(
My IDL software site gets quite a few hits and appears fairly high in Google
searches, but only, I suspect, because there's a link to it on David's page.
As far as I am aware, I am the only person who has ever actually *used* the
code I write.
I get the occasional "Hey nice stuff, I must take a look at it some time"
message and I once got a "I tried it and it didn't work!"
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand
|
|
|
|
| Re: Using Comm... err, alternative? [message #21181 is a reply to message #21180] |
Thu, 17 August 2000 15:08  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"Pavel Romashkin" <promashkin@cmdl.noaa.gov> wrote in message
news:399C243A.8EAF52C6@cmdl.noaa.gov...
> David Fanning wrote:
>>
>> The "self" object
>> reference comes immediately to mind, but then your
>> user is going to know for sure that this thing is an
>> object and run like hell in the other direction. :-(
>
> This is *exactly* what I am thinking. I wanted to make this PLOT
> substitute (re-inventing the wheel again) so transparent that they have
> no clue they use object graphics :-) I'll release it when this thread is
forgotten.
And here I am trying to make direct graphics more object-like:
; Plot a map in one window
odg0 = obj_new('MGHdgWindow', DIMENSIONS=[400,400])
odg0->plot, '!p.color = 255 & !p.background = 0', /EXECUTE
odg0->plot, 'map_set', 0, 170, LIMIT=[-50,160,-30,180], /ISOTROPIC,
/MERCATOR
odg0->plot, 'map_continents', /HIRES, /FILL_CONTINENTS
; A line plot in another window (with different colours)
odg1 = obj_new('MGHdgWindow', DIMENSIONS=[450,350], RESIZEABLE=0)
odg1->plot, '!p.color = 0 & !p.background = 255', /EXECUTE
odg1->plot, 'plot', findgen(100000)
; Go back and add something to the map.
odg0->refresh
odg0->plot, 'map_grid'
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand
|
|
|
|
| Re: Using Comm... err, alternative? [message #21182 is a reply to message #21181] |
Thu, 17 August 2000 00:00 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
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.
Am I being obtuse or couldn't you just use the provided !D.WINDOW sysvar in the
focus event callback simply as:
widget_control,self.mywin,get_value=win
wset,win
I do this all the time at the same time as resetting colors. All plot commands
then go to the relevant chosen window. One issue is with using tracking events
for the callback, so that by the time the user has returned to the command line,
another window has been unintentionally entered. You can also try expose and/or
keyboard focus events.
Or is this an object graphics thing? I'm embarrassed to say that I have yet to
invoke a single O.G. command. Too many case changes and underlines make my code
ugly (IDL_ThisDISPlays_a_VIEWofaModel_withinAConTainerofWindowsgr dotcom).
JD
--
J.D. Smith /*\ WORK: (607) 255-6263
Cornell University Dept. of Astronomy \*/ (607) 255-5842
304 Space Sciences Bldg. /*\ FAX: (607) 255-5875
Ithaca, NY 14853 \*/
|
|
|
|
|
|
| Re: Using Comm... err, alternative? [message #21185 is a reply to message #21181] |
Thu, 17 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
Mark Hadfield wrote:
>
> And here I am trying to make direct graphics more object-like
No offence meant, Mark. To me, object syntax with -> is not worse than
typical procedure syntax with a comma. I guess I am just following the
Man Ahead of the Pack :-) who writes his widgects to replace CW_* stuff
so that noone can guess he used objects in reality. I may send my
"Display" to him first so that he can market it once I hide that Common
block and Heap_gc :-)
Cheers,
Pavel
|
|
|
|
| Re: Using Comm... err, alternative? [message #21186 is a reply to message #21181] |
Thu, 17 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> And here I am trying to make direct graphics more object-like:
Oh, it's an admirable mission. But have you checked your
ftp logs? Pavel and I (and Ben, of course, it goes without
saying) are the only ones who have downloaded the darn things. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Using Comm... err, alternative? [message #21191 is a reply to message #21182] |
Thu, 17 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
Thanks Liam. I read the whole section on Xregistered yesterday but got
so confused by the end that could take no advantage at all of whats in
there. I'll look again, but like you said, relying on Xmanager's common
block is not any worse than making my own. Besides, they can change
things in theirs and that would make my code confused.
Thank you,
Pavel
|
|
|
|
| Re: Using Comm... err, alternative? [message #21192 is a reply to message #21182] |
Thu, 17 August 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
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
for XREGISTERED:
"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."
[stuff deleted]
"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,
but whatever):
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.
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Using Comm... err, alternative? [message #21194 is a reply to message #21182] |
Thu, 17 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
David Fanning wrote:
>
> The "self" object
> reference comes immediately to mind, but then your
> user is going to know for sure that this thing is an
> object and run like hell in the other direction. :-(
This is *exactly* what I am thinking. I wanted to make this PLOT
substitute (re-inventing the wheel again) so transparent that they have
no clue they use object graphics :-) I'll release it when this thread is forgotten.
For the lack of Voodoo I'll settle for Common block (I won't even know
its there since they don't display in my Variable watch window anyway :(
Cheers,
Pavel
|
|
|
|
| Re: Using Comm... err, alternative? [message #21195 is a reply to message #21182] |
Thu, 17 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
> 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.
I think the only alternative to a Common block would
be to make the initial "Plot" command a function that
returned some kind of reference, which the user could
keep track of to do the "overplot". The "self" object
reference comes immediately to mind, but then your
user is going to know for sure that this thing is an
object and run like hell in the other direction. :-(
Cheers,
David
P.S. I looked "object" up in my dictionary and I find
no reference to "voodoo" or "werewolf" anywhere. I don't
know where the notion that these things are to be
avoided came from.
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Using Comm... err, alternative? [message #21198 is a reply to message #21195] |
Thu, 17 August 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
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.
> These things seem just a bit overzealous to me.
> There are a LOT of keyboard focus events, apparently,
> because I find them doing a LOT of drawing. They are
> making me nervous. I don't like anyone who is so *eager*. :-(
I have not had problems with focus events. I haven't used them
everywhere (and, in fact, with *keyboard*), but in this case, when all I
have is a base widget and a draw widget, it seems to me that the only
time I get events returned is when I put the base in the foreground or
background (by clicking a mouse button). Am I missing something?
Cheers,
Pavel
|
|
|
|
|
|
| Re: Using Comm... err, alternative? [message #21214 is a reply to message #21208] |
Wed, 16 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> widget_control, self.top, TIMER=3600 ?
Something like that. :-)
I had a birthday this week and, of course, I draw
someone half my age for my first match in the tennis
tournament last night. I'm beginning to hate kids. :-(
We are battling it out. The kid has a wicked serve
he cranks right into my body. I can barely get my
privates out of the way, let alone hit it back. But
he is not handling my (slower) serve any better.
He somehow manages to win the first set in a tie-breaker,
but I'm not thinking of losing by any stretch of the
imagination. We keep battling. One of the best matches
I've played this summer.
We are 4-4 in the second when I hit a wicked approach
shot, which he someone gets back over the net, barely.
I rush in, s-t-r-e-t-c-h and hit the volley, but YIKES!
I can't move my feet as fast as I used to and I'm stepping
on my racket. WHAM! Face planted on the court. Ankle hurts
like hell.
Can I continue? Hell, yes, I think. But I can't put
any weight on the foot. It's been a great match, the
kid deserves to win as much as I do, so I offer to play
it out, as a courtesy. He hits three drop shots in the
next game, which I look at disdainfully. He wins 6-4.
Headline in today's paper: WhatsHisName Upsets Fanning, No 2 Seed!!!!!
Aaaaahhhhhaaaa. It's hell to grow old.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Using Comm... err, alternative? [message #21215 is a reply to message #21214] |
Wed, 16 August 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Pavel Romashkin <promashkin@cmdl.noaa.gov> wrote in message
news:399B1A1A.F9980995@cmdl.noaa.gov...
> I have a short question. When you have several (identical, object
> plotting only) widget windows, how do you find out which one is the
> topmost without using a common block or defining a main-level variable?
> I use focus events all right, but I have not figure out where to keep
> the resulting information.
> I certainly will use a pointer if all those daughter windows are
> generated from a parent widget program. But how do I do this if I create
> them from a command line?
If you need to access an active non-modal widget from the command line
without using an a-priori reference (such as an object), then I think you
have to use either a common block or a user-defined system variable which
stores information about the widget. See Paul van Delst's WPLOT and WOPLOT
for an example of a case where this is required:
http://airs2.ssec.wisc.edu/~paulv/#idl
If anyone knows another way, let's hear it!
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Using Comm... err, alternative? [message #21216 is a reply to message #21215] |
Wed, 16 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Pavel Romashkin (promashkin@cmdl.noaa.gov) writes:
> I have a short question. When you have several (identical, object
> plotting only) widget windows, how do you find out which one is the
> topmost without using a common block or defining a main-level variable?
> I use focus events all right, but I have not figure out where to keep
> the resulting information.
> I certainly will use a pointer if all those daughter windows are
> generated from a parent widget program. But how do I do this if I create
> them from a command line?
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?
Enquiring minds want to know... :-)
Speaking of keyboard focus events. I'm writing the
"color protection" section of my new widget programming
chapter even as we speak. I've used a variety of color
protection schemes in the past, but this time I thought
I would teach people to use keyboard focus events,
since these seemed to me to be fairly "automatic".
In other words, you don't have to do a whole lot
of coding to make it work. Whenever you get a
keyboard focus event, load the program's color
vectors and redraw the graphic display if you are
on a 24-bit display. Perfect.
But...
These things seem just a bit overzealous to me.
There are a LOT of keyboard focus events, apparently,
because I find them doing a LOT of drawing. They are
making me nervous. I don't like anyone who is so *eager*. :-(
I'm thinking of going back to something a little more
my own speed.
Has anyone else had this experience? What do you use
for color protection? My only requirement is that it
be device-depth and device-decomposed state independent.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
