Posted by
Peter Kenny-2 on
Jul 08, 2004; 9:10am
URL: https://forum.world.st/Drawing-graphs-iin-Dolphin-tp3370875p3370920.html
"Bill Schwab" <
[hidden email]> wrote in message
news:cchk52$ibq$
[hidden email]...
> Chris
> > It's really just a labelling issue. The only real difference between a
Model
> > and any other Object is that a Model as an optimised implementation of
the
> > Observer pattern (#trigger, #when:send:to:, etc).
>
> At the risk of confusing Peter (but he seems like he's ready for
> this<g>), objects can be "models" without being derived from Model. You
> are, of course, very correct about the optimizations for events, but
> that is not essential to serve as a view's #model.
>
> Peter, it is probably most important that you concentrate on building
> something (one might say anything) that works without being too
> concerned with details. Following some of the suggestions in this
> thread will spare you some of the false starts that a few of us
> obviously have in common. Once you have something the produces graphic
> output, you can begin to enhance it. Feel free to ask for advice on
> where to put your more presentation-oriented features, etc.
>
> In general, a good approach to Smalltalk (by no means original to me)
> is: (1) make it run; (2) make it work; (3) make it fast.
>
> Smalltalk's flexibility allows you to make fairly sweeping changes with
> little backlash (most of the time). Probably the first snag that you
> should work to avoid is having errors in #onPaintRequired:. Chris traps
> them (as do I in views); I generally draw to a bitmap first so errors
> are not a problem, and simply lead to a walkback and then a debugger.
> In fact, I generally don't bother with a presenter as I start a new
> graphic; I write code to open an image presenter on the output only when
> I _don't_ see a walkback :)
>
> Have a good one,
>
> Bill
Bill
Thanks for this advice. I seem to have hit on some of these approaches
myself, while trying to follow the advice from people in this group. I now
have a graphing system which works a bit. The top-level presenter selects up
to three functions of time for plotting and passes them as an
OrderedCollection to a Graph class method, which generates a graph object,
and then the top presenter assigns this object as the model of the graph
pane. The #onPaintRequired: method of the pane sends #drawOn:withRect: to
the graph object, which draws itself in the specified rectangle of the
specified canvas. The resulting graph scales itself to a 'sensible' range
and grid interval and then draws a dashed background grid and the selected
functions. There are no labels of any kind as yet, not even scales on the
axes.
One advantage of the incremental approach is that you can review your design
objectives in the light of what you have done. Yesterday, having played with
the window with a graph pane working (it redraws instantly when I switch to
a different set of data), I realised that a graph for interactive use as a
diagnostic tool in an analysis is not the same thing as a presentation graph
for use in a report, and it is daft to conflate the two. So I shall not be
adding much in the way of labelling to the graph, just numbers on the axes,
because all the relevant information is available in other panes. This way I
get the maximum space (and maximum visible detail) for the plot itself. If
users want to save the plot as a presentation quality graph, that can be
added later in a separate editable window.
Thanks for the offer of future advice. I feel more confident having got this
far, but I shall probably be back!
Peter
>
> --
> Wilhelm K. Schwab, Ph.D.
>
[hidden email]