|
0
|
1 {\rtf0\ansi{\fonttbl\f0\fswiss Helvetica;\f2\fmodern Courier;\f1\fmodern Ohlfs;}
|
|
|
2 \paperw9840
|
|
|
3 \paperh11200
|
|
|
4 \margl120
|
|
|
5 \margr120
|
|
|
6 \pard\tx520\tx1060\tx1600\tx2120\tx2660\tx3200\tx3720\tx4260\tx4800\tx5320\f0\b0\i0\ulnone\fs24\fc0\cf0 \
|
|
|
7 Here's why this thing exists. You'll notice from the dates that it's taken me quite a while to get around to actually doing this; it ended up being quite simple to get it put together. (What took me so long is the fact that in the meantime I had to write a simple optimizing compiler for one of my classes, and only had three weeks to do it in.) The tree object just happens to be an enhancement of the object I used/subclassed to build the parse tree in the aforementioned compiler, so I know that the Tree class can be useful, at any rate.\
|
|
|
8 \
|
|
|
9 The other classes in here won't be particularly useful to most folks, but there are examples of (1) multiple .nib files, (2) simple use of multiple documents±notice that I don't track multiple instances except as I open them, so the Windows menu and the user's mouse clicks do all the work here±I didn't really have to do anything special to get it to work, in other words, since NeXTSTEP does this for me. There's also examples of using an Open Panel and of getting the WorkSpace to open double-clicked documents. All this stuff is easy to do anyway, but I suppose that this program could serve as an example for the beginner.\
|
|
|
10 \
|
|
|
11 As you'll notice from below, the main thing to show is how to use PostScript to draw lines and how to display the tree. For most folks, the Tree object±and not this part±will be useful, but it's all in there with everything else for you to look at. You'll notice that I took the simplest and least efficient route to implement the drawing, thus it should make sense to a beginner. For better performance, other methods (described in the Adobe Purple book primarily) could be used. I figured that simply calling the PS() functions would be good enough here, but ideally a PS wrap or better would be used. Also, I redraw the entire View every time even though I should really check the arguments to -drawSelf:: so that only the necessary parts get redrawn. Although that would improve performance, it wasn't worth bothering with for this program.\
|
|
|
12 \
|
|
|
13 My notes about the program are included in the message below in
|
|
|
14 \i italics
|
|
|
15 \i0 .\
|
|
|
16 \
|
|
|
17
|
|
|
18 Date: Thu, 18 Mar 93 19:01:39 -0500\
|
|
|
19 From: Bob Weiner <weiner@pts.mot.com>\
|
|
|
20 Message-Id: <9303190001.AA02300@info.>\
|
|
|
21 To: yackd@maine.et.byu.edu\
|
|
|
22 In-Reply-To: Don Yacktman's message of Thu, 18 Mar 93 16:34:14 -0700 <9303182334.AA29304@maine.et.byu.edu>\
|
|
|
23 Subject: Re: Anyone have a tree display class that can read a tree from a text file?\
|
|
|
24 Status: R\
|
|
|
25
|
|
|
26 \f0\fs24 \
|
|
|
27 \
|
|
|
28 The tree class could read in a tree from\
|
|
|
29 a file in textual form. The first line is the name of the tree.\
|
|
|
30 In textual form, each node in the tree is given by its label, which can be\
|
|
|
31 any text, including spaces on a single line. The node's position in the tree\
|
|
|
32 is given by its preceding indentation, normally using 3 spaces of indentation\
|
|
|
33 per level (the amount can be figured out by examining the first indented\
|
|
|
34 label and counting its spaces. An example:\
|
|
|
35 \
|
|
|
36
|
|
|
37 \f2 Tree Name\
|
|
|
38 Root\
|
|
|
39 Node 1\
|
|
|
40 Node 1.1\
|
|
|
41 Node 1.1.1\
|
|
|
42 Node 2 has this longer label.\
|
|
|
43
|
|
|
44 \f0 \
|
|
|
45
|
|
|
46 \i I read in the first two lines with the assumption that there is no indentation. On the third line, I use the number of spaces to determine the indent. Do not use tabs; I didn't bother to write code which can deal with them. Be sure that the file ends with ".tree" so that the app will load it. If you make the file incorrectly, you will cause weird things to happen, since I didn't bother to do much error checking while parsing. Obviously, for this program to be more "useful" that ought to be rectified.\
|
|
|
47
|
|
|
48 \i0 \
|
|
|
49 After the tree is read in, it is displayed within a new view. Each node is\
|
|
|
50 created as a selectable button with the appropriate label and lines\
|
|
|
51 connecting it to its parent and children. (Let's assume only one button can\
|
|
|
52 be selected at a time.)\
|
|
|
53 \
|
|
|
54
|
|
|
55 \i For simplicity's sake, all buttons are the same size. If the node's label is really long or really short, this might cause a problem. The View would have to do tricky calculations in order to do better, and I deamed this a "not worth bothering with" thing.\
|
|
|
56
|
|
|
57 \i0 \
|
|
|
58 When a button is selected, a string consisting of the tree name and the node\
|
|
|
59 selected is sent to an output stream. (stdout is fine as a default.), e.g.\
|
|
|
60 \
|
|
|
61 Tree Name^^Node 1.1 \
|
|
|
62 \
|
|
|
63 could be output with ^^ indicating separation of the two arguments.\
|
|
|
64 \
|
|
|
65
|
|
|
66 \i This is what I do. If launched from Workspace, look for the text in the Console window, which is where stdout goes to. It would probably be better to have a UI "Console" window for this output and allow the user to select a file to "save" to, but it wasn't worth the effort to this this here, easy though it is.\
|
|
|
67
|
|
|
68 \i0 \
|
|
|
69 That's it. Then my other program takes this standard output and displays\
|
|
|
70 text associated with the selected node.\
|
|
|
71 \
|
|
|
72 \
|
|
|
73
|
|
|
74 }
|
