comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: selecting model objects
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: selecting model objects [message #20790 is a reply to message #20788] Wed, 26 July 2000 00:00 Go to previous messageGo to previous message
Mark Hadfield is currently offline  Mark Hadfield
Messages: 783
Registered: May 1995
Senior Member
"Rick Towler" <rtowler@u.washington.edu> wrote in message
news:397CE43B.78DEAA48@u.washington.edu...
>
> I have a base model (a map) that contains other models (geographic
> data). I need to select data within the map using the IDLgrWindow
> Select method. Right now I am only getting the base model returned.
>
> object hierarchy is: [data_model]->[map_model]->[oView]->[oWindow]
>
> ; my select code
> item = oWindow->Select(oView, [event.x, event.y])
>
> item contains the reference to map_model only.
>
> A key point is that I need to anchor the geographic data to the map and
> I need to be able to translate and scale the map. Because of this I
> haven't been able to add the data objects directly to the view since
> each of the objects would translate/scale independently and the
> geographic data would be dereferenced from the underlying map.
>
> is it possible to select a model (or atom) that is contained in another
> model that is contained in a view?
>
> If not, is there a way to "join" 2 or more models so when translating or
> scaling they behave as 1?
>
> thanks!
>
> -Rick Towler

Hmmm. I'm not *sure* I understand what you're trying to do or what the
problem is, but here goes...

You want to translate/scale/rotate map_model in response to mouse events?
Bear in mind that if you know which model you want to move, then you don't
need to call Select at all. You can keep track of the relevant model's
object reference in the object structure, or maybe you know its position in
the view container so you can track it down with one or more Get operations.
Then just translate/scale/rotate that model based on event.x & event.y.

I have example code that works this way in:

http://katipo.niwa.cri.nz/~hadfield/gust/software/idl/mghgrw indow__define.pr
o

though I don't know if looking at it will help--I find it hard to figure it
out myself! An MGHgrWindow doesn't know much at all about its GRAPHICS_TREE,
but it does assume that translation, scaling and rotation always work on the
first model in each view. This isn't really too restrictive.

As always, if you want to use one of the routines from my library, you'd
better get the lot, in:

http://katipo.niwa.cri.nz/~hadfield/gust/software/idl/MARKS_ ROUTINES.tar.gz
http://katipo.niwa.cri.nz/~hadfield/gust/software/idl/MARKS_ ROUTINES.zip

---
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
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: PV-Wave vs AXUM w/ S-PLUS
Next Topic: Re: IDLgrPolyline

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 05:14:18 PDT 2025

Total time taken to generate the page: 1.52181 seconds