comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: Keyword precedence

Re: Keyword precedence
type: item
description: Mark Hadfield (m.hadfield@niwa.cri.nz) writes: > The documented behaviour for IDL--the behaviour to which Jeff was > referring--is specified in the following quote from "Building IDL > Applications" > > Note that keywords passed into a routine via _EXTRA override > previous settings of that keyword. For example, the call: > > PLOT, a, b, COLOR=color, _EXTRA={COLOR: 12} > > specifies a color index of 12 to PLOT. > > Contrary to what I wrote a month ago, I think this is usually the desired > behaviour, because it makes it easy to write wrapper routines. I absolutely agree that this is the desired behavior. It's just that it buggers your programs occasionally and makes you wish for the opposite behavior. :-( I'm referring, of course, to those occasions when you absolutely, positively DON'T want the damn color to be mucked around with. Then you have to go fishing for the COLOR keyword in the extra structure. It would be OK if you could do something like this: fields = Tag_Names(extra) index = Where(fields EQ 'COLOR', count) IF count GT 0 THEN extra.color = 127 But, of course, the user didn't use COLOR as the keyword. They used C, CO, COL, COLO, or some other thing, and you have to fish those things out as well. I say it's easier to write somewhere in the program documentation: "And another thing. Don't touch the friggin' COLOR keyword!!!!" But this comes up so rarely (I'm really easy with respect to color and tolerate a lot of diversity), that I don't mind the current behavior at all. > For example, > taking the PLOT example, one can imagine a MY_PLOT routine, a wrapper for > PLOT, that specifies its own default for colour: > > pro my_plot, a, b, _EXTRA=extra > plot, a, b, COLOR=127, _EXTRA=extra > end > > MY_PLOT will plot data in color 127 unless the caller overrides it by > specifying a COLOR keyword. If we can't rely on the documented behaviour > then we have to make MY_PLOT more complicated, thus: > > pro my_plot, a, b, COLOR=color, _EXTRA=extra > if n_elements(col…
creator: davidf
date: 2000-08-24T07:00:00-00:00

Re: Keyword precedence
type: item
description: "David Fanning" <davidf@dfanning.com> wrote in message news:MPG.140f8856ff9c2a24989bf1@news.frii.com... > I'm referring, of course, to those occasions when you > absolutely, positively DON'T want the damn color to > be mucked around with. Then you have to go fishing > for the COLOR keyword in the extra structure. It would > be OK if you could do something like this: > > fields = Tag_Names(extra) > index = Where(fields EQ 'COLOR', count) > IF count GT 0 THEN extra.color = 127 > > But, of course, the user didn't use COLOR as the keyword. > They used C, CO, COL, COLO, or some other thing, and > you have to fish those things out as well. Thanks for your comments, David. It's nice to know that somebody reads my raves. Why not pro my_plot, COLOR=color, _EXTRA=extra if n_elements(color) gt 0 then $ message, /INFORM, "I'm plotting this in color index 127 whatever you say!" plot, COLOR=127, _EXTRA=extra end or my preference pro my_plot, COLOR=color, _EXTRA=extra if n_elements(color) gt 0 then $ message, "Don't touch the friggin' COLOR!" plot, COLOR=127, _EXTRA=extra end > I think if a keyword is important, define it, and define > a default value for it. I wouldn't change any of your fine > code a bit, Mark. I already have done in one or two places. It got clearer, in my opinion. But it's a matter of taste. There's nothing stopping me from writing in the comments header: COLOR: As for plot, but default is 127. > Actually, I think this code is working exactly the way > it is suppose to work. (Someone is going to have to pry > JD away from this thesis for the definitive answer. I'm > slightly confused about it too.) At the moment when I write foobar, COLOR=0, _EXTRA={color:12} then if foobar is a wrapper for some other function (and foobar itself doesn't have a COLOR keyword) I have to know whether foobar uses reference or value inheritance to know what the effect will be. This can't be right! Of course I don't actually write the above command, not unless I'm messing about tryi…
creator: Mark Hadfield
date: 2000-08-25T04:03:36-00:00

Re: Keyword precedence
type: item
description: J.D. Smith (jdsmith@astro.cornell.edu) writes: > > Final synopsis: You want to play with the _EXTRA structure? You've got to use > the _EXTRA mechanism. JD, I know you are working on your thesis, so here is a tip for you. Put this kind of information in an Executive Summary at the TOP of your article or thesis, not at the very bottom. It will save a lot of head scratching and your thesis advisors will appreciate already understanding whatever it is you are tying to say. :-) Cheers, David P.S. I have to say, you never disappoint me with your understanding of these issues. I really appreciate it. Thanks. -- 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
creator: davidf
date: 2000-08-25T07:00:00-00:00

Re: Keyword precedence
type: item
description: David Fanning wrote: > > Mark Hadfield (m.hadfield@niwa.cri.nz) writes: > >> The documented behaviour for IDL--the behaviour to which Jeff was >> referring--is specified in the following quote from "Building IDL >> Applications" >> >> Note that keywords passed into a routine via _EXTRA override >> previous settings of that keyword. For example, the call: >> >> PLOT, a, b, COLOR=color, _EXTRA={COLOR: 12} >> >> specifies a color index of 12 to PLOT. >> >> Contrary to what I wrote a month ago, I think this is usually the desired >> behaviour, because it makes it easy to write wrapper routines. > > I absolutely agree that this is the desired behavior. It's > just that it buggers your programs occasionally and makes you > wish for the opposite behavior. :-( > > I'm referring, of course, to those occasions when you > absolutely, positively DON'T want the damn color to > be mucked around with. Then you have to go fishing > for the COLOR keyword in the extra structure. It would > be OK if you could do something like this: > > fields = Tag_Names(extra) > index = Where(fields EQ 'COLOR', count) > IF count GT 0 THEN extra.color = 127 > > But, of course, the user didn't use COLOR as the keyword. > They used C, CO, COL, COLO, or some other thing, and > you have to fish those things out as well. > > I say it's easier to write somewhere in the program > documentation: > > "And another thing. Don't touch the friggin' COLOR keyword!!!!" > > But this comes up so rarely (I'm really easy with respect to > color and tolerate a lot of diversity), that I don't mind the > current behavior at all. > >> For example, >> taking the PLOT example, one can imagine a MY_PLOT routine, a wrapper for >> PLOT, that specifies its own default for colour: >> >> pro my_plot, a, b, _EXTRA=extra >> plot, a, b, COLOR=127, _EXTRA=extra >> end >> >> MY_PLOT will plot data in color 127 unless the caller overrides it by >> specifying a COLOR keyword. If we can't rely on the documented behaviour >> then we have t…
creator: John-David T. Smith
date: 2000-08-25T07:00:00-00:00

Re: Keyword precedence
type: item
description: "Mark Hadfield" <m.hadfield@niwa.cri.nz> wrote in message news:967252103.29393@clam-ext... > > With the third one, 12 is printed in every case! My interpretation: IDL's > handling of keyword abbreviations is such that an abbreviated keyword takes > precedence over a non-abbreviated one, and this overrides the "fully > by-reference first" rule. This isn't quite true either. Further experimentation, left as an exercise for the reader, establishes that the "fully by-reference first" rule only applies when the conflicting keywords have identical names. If the user-supplied keyword name to MGH_EXAMPLE_KEYWORDS is shorter *or* longer than the default it's supposed to override, then the user-supplied value wins every time. I guess the point is that the reference inheritance mechanism only has to choose between conflicting keywords when they are represented by (case-insensitively) identical strings. Otherwise it just passes them both through to the next level, where they are dealt with properly. --- 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
creator: Mark Hadfield
date: 2000-08-26T01:27:41-00:00

Re: Keyword precedence
type: item
description: Mark Hadfield wrote: > > "J.D. Smith" <jdsmith@astro.cornell.edu> wrote in message > news:39A6B82E.2533B5A@astro.cornell.edu... >> ..... > > Whew! Thanks for that explanation, JD. I think I understand it now. > > First an executive summary for David: > > * IDL's current behaviour regarding precedence of explicit keywords vs those > passed through from above by inheritance is too inconsistent to be useful. > It requires the caller to know details about inheritance mechanisms further > down the chain, which is highly undesirable. > > Now a few questions/comments: > >> You can actually see this happening if you throw an "print, >> arg_present(color)" into KEYWORDS_PRINT_COLOR. > > I did. It prints 0 in all 3 cases. What does this tell me? ARG_PRESENT is > only supposed to return 1 if a named variable is supplied. I didn't supply > one. I guess I neglected to say if you do pass a named variable in addition to the explicit _EXTRA={}. > >> Of course, only one of these can be used, and as it >> happens, the fully by-reference variable is chosen. > > This is the crux, isn't it? Could & should this design choice be changed? If > it were, would this lead to any other surprising results? I commented briefly before to indicate that really this should not be changed, but _REF_EXTRA should be changed to detect duplicate keyword passings and make it an error. Without this error, the behaviour is confusing, I agree. RSI went to far to ease acceptance of _REF_EXTRA, I belive. > > This is my main point and I could leave it there but I'll add another > tidbit: > > I modified MGH_EXAMPLE_KEYWORDS & played with it a > bit more. I've put the modified code on the WWW page and attached it to this > message. Now the main routine accepts _EXTRA keywords from its caller. Its > usage now reflects the intention of the whole exercise better. The idea is > that we want to pass COLOR=0 through to the printing routine but let the > user override it. (I hope nobody thinks I ever actually *write* cod…
creator: John-David T. Smith
date: 2000-08-26T07:00:00-00:00

Re: Keyword precedence
type: item
description: "John-David Smith" <jdsmith@astro.cornell.edu> wrote in message news:39A874F3.D91EC14F@astro.cornell.edu... > Mark Hadfield wrote: >> "J.D. Smith" <jdsmith@astro.cornell.edu> wrote in message >> news:39A6B82E.2533B5A@astro.cornell.edu... >>> ..... >> Whew! Thanks for that explanation, JD. I think I understand it now. Well, I didn't, but I'm getting there. > ... I think this was a slippery slope, since overriding a > *value* is very different than overriding a *variable*. > The former is relatively more straightforward. > If RSI had stuck to a _REF_EXTRA used only for returning values > up inherited keywords in chains of calls, we wouldn't have > this ambiguity... it really doesn't make sense to override the > *location in memory* associated with a given > inherited keyword variable at runtime... You'll be relieved to hear that I've finally grasped this point. I was focussed entirely on passing information *inwards* through the chain of calls. But before we give up entirely, let's consider the following again: IDL> mgh_example_keywords, COLOR=12 % MGH_EXAMPLE_KEYWORDS: Calling color-print routine directly % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 12 % MGH_EXAMPLE_KEYWORDS: Calling color-print routine via value wrapper % MGH_EXAMPLE_KEYWORDS_VALUE_WRAPPER: Passing along EXTRA keywords by value: COLOR{ 12} % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 12 % MGH_EXAMPLE_KEYWORDS: Calling color-print routine via reference wrapper % MGH_EXAMPLE_KEYWORDS_REFERENCE_WRAPPER: Passing along EXTRA keywords by reference: COLOR COLOR % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 0 A key difference between the value wrapper and the reference wrapper is that the former passes only one keyword (which it sees as the structure {COLOR: 12}) down to the next level, whereas the the reference wrapper passes both, (which it sees as the string array ['COLOR', 'COLOR']). Now that you've explained it, I see that that the reference wrapper retains both because either of them might point to a v…
creator: Mark Hadfield
date: 2000-08-27T23:23:50-00:00

Re: Keyword precedence
type: item
description: Mark Hadfield wrote: >>> Whew! Thanks for that explanation, JD. I think I understand it now. > > Well, I didn't, but I'm getting there. > >> ... I think this was a slippery slope, since overriding a >> *value* is very different than overriding a *variable*. >> The former is relatively more straightforward. >> If RSI had stuck to a _REF_EXTRA used only for returning values >> up inherited keywords in chains of calls, we wouldn't have >> this ambiguity... it really doesn't make sense to override the >> *location in memory* associated with a given >> inherited keyword variable at runtime... > > You'll be relieved to hear that I've finally grasped this point. I was > focussed entirely on passing information *inwards* through the chain of > calls. > > But before we give up entirely, let's consider the following again: > > IDL> mgh_example_keywords, COLOR=12 > % MGH_EXAMPLE_KEYWORDS: Calling color-print routine directly > % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 12 > % MGH_EXAMPLE_KEYWORDS: Calling color-print routine via value wrapper > % MGH_EXAMPLE_KEYWORDS_VALUE_WRAPPER: Passing along EXTRA keywords by value: > COLOR{ 12} > % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 12 > % MGH_EXAMPLE_KEYWORDS: Calling color-print routine via reference wrapper > % MGH_EXAMPLE_KEYWORDS_REFERENCE_WRAPPER: Passing along EXTRA keywords by > reference: COLOR COLOR > % MGH_EXAMPLE_KEYWORDS_PRINT_COLOR: COLOR is 0 > > A key difference between the value wrapper and the reference wrapper is that > the former passes only one keyword (which it sees as the structure {COLOR: > 12}) down to the next level, whereas the the reference wrapper passes both, > (which it sees as the string array ['COLOR', 'COLOR']). > > Now that you've explained it, I see that that the reference wrapper retains > both because either of them might point to a variable to be modified on > output. By the way, in IDL 5.1 and before, the value wrapper also passed > both keywords as {COLOR: 0, COLOR: 12} and the color-prin…
creator: John-David T. Smith
date: 2000-08-28T07:00:00-00:00

Re: Keyword precedence
type: item
description: Mark Hadfield and John-Cavid Smith had a long discussion in which Mark wrote at some point: > > I think the rule should be, where a choice has to be made between duplicate > keywords, always choose the last one in the list. > now for the slow-movers: does this mean that wrapper, color=12, _Extra=e and wrapper, _Extra=e, color=12 should yield different results if there is a color tag in the extra structure? I could see some benefits to this, but it would alter the whole idea of keywords being position independent as opposed to parameter arguments. Although this may seem overly formal, I would argue that the "convenience" gained by overriding keywords that are explicitely set with values in the extra structure does not aid in writing "clean" programs. If you are messing with any particular property in your routines, this property should always be identified by having its own keyword in my opinion. So, if you want a default color, the procedure header should be something like: pro wrapper, color=color, _EXTRA=e IF N_Elements(color) EQ 0 THEN color = 12 plot, x,y, color=color, _EXTRA=e end and the "real" color keyword should be used (which I think and hope it gets). Conclusions (these tend to come near the end of an article ;-): I agree with JD that IDL should be stricter and issue an error if it finds more than 1 keyword of the same name in a _ref_extra list, and perhaps it should even be possible to generate an error if the two identical keywords appear in the _extra list (another compile_opt flag?). Cheers, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 41173-298 [[ [[ martin.schultz@dkrz.de [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
creator: Martin Schultz
date: 2000-08-28T07:00:00-00:00

Re: Keyword precedence
type: item
description: "Mark Hadfield" <m.hadfield@niwa.cri.nz> writes: > It's interesting that David Fanning and Martin Shultz have both recommended > the following idiom for establishing overridable defaults > > pro my_plot, COLOR=color, _EXTRA=extra > if n_elements(color) eq 0 then color = 12 > plot, COLOR=12, _EXTRA=extra **** Ooops ^^ **** > end > > This has the effect, unintended and normally irrelevant, that if the > following call is made with the COLOR keyword set to an undefined variable > > my_plot, COLOR=color > > then this variable is set to 12 on output. It isn't too hard to imagine a > situation (successive calls to different routines with different default > colours) where this will bite an unwary programmer, though in several years > of using this idiom I have seldom thought about this side-effect and have > very seldom been bitten. I have had a difficult time keeping up with this thread. Whew! I often do my keyword passing with the following draconian but safe technique. pro my_plot, COLOR=color0, _EXTRA=extra if n_elements(color0) eq 0 then color = 12 $ else color = floor(color0(0)) plot, COLOR=color, _EXTRA=extra end COLOR0 is the value passed in, which is distinct from the value of the local variable COLOR. I agree. It's ugly. Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
creator: Craig Markwardt
date: 2000-08-28T07:00:00-00:00

Re: Keyword precedence
type: item
description: Mark Hadfield (m.hadfield@niwa.cri.nz) writes: > Now to control (say) the X axis the caller just sets xaxis_properties equal > to a structure containing the appropriate keyword:value pairs, e.g.: > > my_visualisation, XAXIS_PROPERTIES={notext:1, minor:0} > > Now this approach obviously relies on the "_properties" structures > overriding the defaults. This is how I've been configuring, for example, the PostScript device for just about forever: ps_device_keywords = PSConfig() Set_Plot, 'PS' Device, _Extra=ps_device_keywords It works great in a nice, controlled environment like PSConfig, where I know *exactly* what keywords are going to be in the structure coming back from it. If I want to make sure a value is set (Color is an obvious one), I can always force it: ps_device_keywords = PSConfig() ps_device_keywords.color = 1 Set_Plot, 'PS' Device, _Extra=ps_device_keywords But I have been much more wary of letting the user create inherited structures, for some of the same reasons you and JD so elegantly describe. But I appreciate the discussion and the time everyone has devoted to figuring this out. It has been extremely helpful. Thank you. 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
creator: davidf
date: 2000-08-28T07:00:00-00:00

Re: Keyword precedence
type: item
description: "Martin Schultz" <martin.schultz@dkrz.de> wrote in message news:39AA2492.6ADB8E0@dkrz.de... > Mark wrote at some point: > >> I think the rule should be, where a choice has to be made between duplicate >> keywords, always choose the last one in the list. > > now for the slow-movers: does this mean that > wrapper, color=12, _Extra=e > and > wrapper, _Extra=e, color=12 > > should yield different results if there is a color tag in the > extra structure? You mean different results from each other, don't you? Definitely not! The "list" here is the list of "extra" keywords inside wrapper (where--to reiterate--wrapper uses reference inheritance and doesn't have a color keyword itself). The information passed in via _extra always goes onto the end of this list. Position in the call doesn't matter (I checked). > Although this may seem overly formal, I would argue that the > "convenience" gained by overriding keywords that are explicitly > set with values in the extra structure does not aid in writing > "clean" programs. If you are messing with any particular property > in your routines, this property should always be identified by > having its own keyword in my opinion. So, if you want a default > color, the procedure header should be something like: > > pro wrapper, color=color, _EXTRA=e > > IF N_Elements(color) EQ 0 THEN color = 12 > plot, x,y, color=color, _EXTRA=e > > end > > and the "real" color keyword should be used (which I think and > hope it gets). David Fanning said the same thing. I see your point, but I think I still favour the overriding form: pro wrapper, _EXTRA=e plot, x,y, color=12, _EXTRA=e end because it's shorter (much shorter if several properties are overridden) and therefore clearer. However I've been happily writing code in the style you advocate for the last couple of years, so it can't be all that bad. Actually my reason for wanting to rely on keyword precedence is a little more complicated, and a little more compelling, than what I described in my p…
creator: Mark Hadfield
date: 2000-08-28T22:07:03-00:00

Re: Keyword precedence
type: item
description: "J.D. Smith" <jdsmith@astro.cornell.edu> wrote in message news:39AA8AFE.CDBAB7E6@astro.cornell.edu... > ...Just as with normal > positional parameters, the programmer must be sure to define in advance how each > will be used: for input values, for return values, or for both. This affects > their usage!... It's interesting that David Fanning and Martin Shultz have both recommended the following idiom for establishing overridable defaults pro my_plot, COLOR=color, _EXTRA=extra if n_elements(color) eq 0 then color = 12 plot, COLOR=12, _EXTRA=extra end This has the effect, unintended and normally irrelevant, that if the following call is made with the COLOR keyword set to an undefined variable my_plot, COLOR=color then this variable is set to 12 on output. It isn't too hard to imagine a situation (successive calls to different routines with different default colours) where this will bite an unwary programmer, though in several years of using this idiom I have seldom thought about this side-effect and have very seldom been bitten. My point: in many situations IDL programmers are pretty relaxed about whether values are modified on output because it has no effect on how their programs operate. As far as possible the language should avoid punishing them for this. > ...More scary is the notion of: > > mgh_example_keywords_reference_wrapper, COLOR=color, _EXTRA=extra > > putting a return value somewhere other than in the variable "color"... maybe not > even on this level... maybe n levels up somewhere. Yes, that would be the effect of my proposals for precedence. And it is the current situation (which acts exactly the way I am proposing except in a specific, albeit common, case). I think you have to accept that by putting _EXTRA or _REF_EXTRA in your code you are passing power, and responsibility to the next level up. > ...I > think you are imagining cases in which you don't have control over the > inheritance chain, and may not know you are using _REF_EXTRA. Yes. And I was b…
creator: Mark Hadfield
date: 2000-08-28T23:32:06-00:00

Re: Keyword precedence
type: item
description: Craig Markwardt wrote: > > "Mark Hadfield" <m.hadfield@niwa.cri.nz> writes: > >> It's interesting that David Fanning and Martin Shultz have both recommended >> the following idiom for establishing overridable defaults >> >> pro my_plot, COLOR=color, _EXTRA=extra >> if n_elements(color) eq 0 then color = 12 >> plot, COLOR=12, _EXTRA=extra > **** Ooops ^^ **** >> end >> >> This has the effect, unintended and normally irrelevant, that if the >> following call is made with the COLOR keyword set to an undefined variable >> >> my_plot, COLOR=color >> >> then this variable is set to 12 on output. It isn't too hard to imagine a >> situation (successive calls to different routines with different default >> colours) where this will bite an unwary programmer, though in several years >> of using this idiom I have seldom thought about this side-effect and have >> very seldom been bitten. > > I have had a difficult time keeping up with this thread. Whew! I > often do my keyword passing with the following draconian but safe > technique. > > pro my_plot, COLOR=color0, _EXTRA=extra > if n_elements(color0) eq 0 then color = 12 $ > else color = floor(color0(0)) > plot, COLOR=color, _EXTRA=extra > end > > COLOR0 is the value passed in, which is distinct from the value of the > local variable COLOR. I agree. It's ugly. > > Craig > > -- > ------------------------------------------------------------ -------------- > Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu > Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response > ------------------------------------------------------------ -------------- No, it's not ugly, it's utmost correct ;-) This is what I do whenever I get caught by the situation that Mark points out - once I discover that my return value is changed *and* that this leads to undesired consequences (which most often it does not, rather the opposite), then I change color to color0 or whatever. To give you an example, where I rely on setting t…
creator: Martin Schultz
date: 2000-08-29T07:00:00-00:00

Re: Keyword precedence
type: item
description: Mark Hadfield wrote: > > for each element foo add a single keyword, > foo_properties, thus: > > pro my_visualisation $ > , VIEW_PROPERTIES=view_properties $ > , XAXIS_PROPERTIES=xaxis_properties $ > , YAXIS_PROPERTIES=yaxis_properties $ > , SURFACE_PROPERTIES=surface_properties $ > , WINDOW_PROPERTIES=window_properties > > theview = new_view(UNITS=2, DIMENSIONS=, _EXTRA=view_properties) > thexaxis = new_axis(DIRECTION=0, TICKFORMAT=..., > _EXTRA=xaxis_properties) > theyaxis = new_axis(DIRECTION=1, TICKFORMAT=..., > _EXTRA=yaxis_properties) > ; Add the axes to a model & add that to the view > ; Get data > thesurface = new_surface(STYLE=2, DATAX=..., _EXTRA=surface_properties) > ; add the surface to the model > new_window, GRAPHICS_TREE=theview, RETAIN=2, _EXTRA=window_properties > end > > Now to control (say) the X axis the caller just sets xaxis_properties equal > to a structure containing the appropriate keyword:value pairs, e.g.: > > my_visualisation, XAXIS_PROPERTIES={notext:1, minor:0} > > Now this approach obviously relies on the "_properties" structures > overriding the defaults. When I first tried this I found that the > xaxis_properties keyword was not working and that this was because I had > happened to use inheritance by reference in new_axis. The rest (as they say) > is history... If you follow this approach, you might almost as well pass the structure explicitely instead of relying on the _extra passing mechanism. Things like this prompted me a while ago to write my little ChkStru routine, where you test (a) if the thing you test is a structure, and (b) if it contains what you are looking for. An example for setting axis properties could look like: IF ChkStru(xaxis_properties, 'DIRECTION') THEN thexaxis->SetProperty, $ direction=xaxis_properties.direction IF ... But I realize, this may get a bit lengthy from time to time ;-) Thanks for the thoughtful discussion, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin…
creator: Martin Schultz
date: 2000-08-29T07:00:00-00:00