nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein) (05/16/89)
I don't see a problem here at all. Why not just write out a standard
reference?
Here, in this message, I am sending an illustration of such a thing. I
*think* this example will work with the released Andrew, but even if it
doesn't, you should be able to get the idea of how the datastream should
look by reading the raw datastream for this message.
What follows, then, are two views on a single dataobject. When you move
the slider around, the bargraph will follow after you let go. By
looking at the datastream of this message, you should be able to see how
this is done. (Of course, if you're reading this via netnews or if you
get the "stripped" list distribution, this won't be very useful. Let me
know and I can send you the message again by personal multimedia mail.)
[An Andrew ToolKit view (sliderv) was included here, but could not be
displayed.]
[An Andrew ToolKit view (bargrphv) was included here, but could not be
displayed.]
Pretty neat, eh? Does that answer your question?
----------------------------------------------------------------------
Nathaniel Borenstein <nsb+@andrew.cmu.edu>
Manager, Andrew Applications Group
Information Technology Center
Carnegie-Mellon University
Pittsburgh, PA 15213
[An Andrew ToolKit view (a raster image) was included here, but could
not be displayed.][An Andrew ToolKit view (an animated drawing) was
included here, but could not be displayed.]wjh+@ANDREW.CMU.EDU (Fred Hansen) (05/17/89)
> Excerpts from ext.in.info-andrew: 15-May-89 Writing data graphs Gregory > Rogers@a.cs.uiuc (1189) > The file would be something like this: > \begindata{aclass,1} > \begindata{bclass,2} > \begindata{dclass,3} > ... d stuff > \enddata{dclass,3} > ... other b stuff > \enddata{bclass,2} > \begindata{cclass,4} > \a_reference_to_an_object_that_has_already_been_filed{dclass,3} > ... other c stuff > \enddata{cclass,4} > ... other a stuff > \enddata{aclass,1} > What should I do with > "a_reference_to_an_object_that_has_already_been_filed"? There is an answer to this question in theATK architecture: Both B and C should refer to their embedded object by the dataobject identifier. If you look at a text data stream, you will find something like \view{sliderv,270125020,2,0,0} which says that at this point in the image a view object of class sliderv should be instantiated looking at data object 270125020. (The 2 is an identifier of this view in the view stream. The 0,0 indicates that the size is not explicit; if the size were explicitly set by the user these values would be non-zero.) If another view is to examine the same data object, it would appear as: \view{bargrphv,270125020,3,0,0} (This and the preceding example are taken from Nathaniel's post about this same topic.) When text encounters a data object in its incoming stream, it does nothing except put it in the dictionary. {See andrew/atk/text/text.c:text__HandleKeyword:(strcmp(keyword, "view") == 0).} The \view data stream item finds the data object in the dictionary and displays it with the view. {See andrew/atk/text/textv.c:CreateMatte.} In future, it is possible that an ATK data stream will be a sequence of data objects, some of which will have references to others. Fred Hansen (412) 268-6788 wjh+@andrew.cmu.edu BITNET: wjh+@andrew for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh Omega say, "Enjoy the raspberries."