Login  Register

Re: Drawing graphs iin Dolphin

Posted by Chris Uppal-3 on Jul 07, 2004; 9:23am
URL: https://forum.world.st/Drawing-graphs-iin-Dolphin-tp3370875p3370907.html

Peter,

> a. Chris - I see the crucial point is that I must have a method for
> #onPaintRequired:, which in turn sends #drawOn: to the model (in this case
> my graph object). I have ensured that the graph object is the model for
> the view I am using, which is still a ScribbleView, and the object has a
> #drawOn: method, which I have single-stepped through with the debugger.
> Everything seems to happen OK, the drawing instructions are issued, but
> nothing appears.

Is it possible that your paintng code is buggy ?  Or that you are drawing in
white on a white background ?


> b. I have obviously got to learn more about views and canvases than I
> really want to know if I am going to crack this. One thing bugs me at the
> moment. Almost all the #onPaintRequired; methods I have found begin:
>     onPaintRequired: aPaintEvent
>     |canvas|
>     canvas := aPaintEvent canvas
> and this provides the canvas for the #drawOn: method. But inside the
> method the canvas has extent = 1280@1024 (i.e. the whole screen) and
> windowExtent = viewportExtent = 1@1. Nothing bears any  relationship to
> the actual extent of the graph window I am trying to draw on.

Yes, that seems to be a problem with Windows, and has been discussed here
before quite recently.  See the thread from May entitled "Very big bitmap
doesn't work".  What I do is to use the View's #clientRectangle or
#clientExtent to determine what to draw on.  Like Bill, I use a painting object
that is logically separate from the View itself, so my #onPaintRequired: is
roughly like:

    onPaintRequired: aPaintEvent
        self painter
            paintOnCanvas: aPaintEvent canvas
            in: self clientRectangle.


> e. There is still a question in my mind as to whether Windows provides
> options for handling .wmf pictures, which maybe OA have chosen not to wrap
> in Dolphin. IPicture class>>fromBitmap: and fromIcon: refer to constants
> PICTYPE_BITMAP = 1 and PICTYPE_ICON = 3. Could there be other picture
> types available?

I've taken a glance through the archives, and it appears that nobody has yet
produced a wrapper for metafiles (unless there's something in the GDIPlus
wrapper ?).  It looks as though it would probably be quite easy for someone who
knows that level of Dolphin/Windows integration to produce, but then, if it
were that easy, surely somebody would have done it by now ;-)


> f. I am still puzzling a bit over MVP strategy. I have a group containing
> a graph model, a graph presenter and a graph view, which is obviously an
> MVP triad as a component. But where does this fit in the MVP framework of
> the whole application. Drawing a graph is part of the user interface, not
> part of the underlying calculation, so it is not part of the overall
> model. So where does my graph object class belong in the object
> hierarchy? - all the classes in the main model are under Model. Is this
> all just a question of labelling, or does it have any implication for the
> functioning of the system?

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).

You may want to consider moving your painting logic out of the Model and into a
separate Painter object that is owned by the View.  That would make sense if
the rendering has aspects (color, fonts to use, graph style, etc) that are not
logically part of the Model itself.


And, from another post:

> At the
> moment I can't generate my view class as a direct subclass of View - or
> rather I don't know how to generate the view resource to go with it.

When you create a custom View, you create a view resource and associate it with
a Presenter class by evaluating an expression like:

     MyPresenter
        addView: MyView
        asResource: 'Default view'.

You only have to do that once.  As far as I can see there is no strong reason
why you should not be able to do the equivalent from the View Composer, but the
fact is that you can't (without some rather desparate hacking, anyway).

View resources are instances of the View class that have been converted into
ByteArrays using the "STB" mechanism, and then saved in the current
ResourceManager.  The reason you need to be aware of that is that if you change
the definition of the View class (change the instance variables) then stored
view resources will likely not load properly.   You can add code to your View
class to convert old resources to the new format on-the-fly if you want (its
straightforward to do), but I assume you don't want to get into that now.  If
not then you'll have to ensure that you re-execute the above expression to
replace the stored resouces if/when you change the layout of your View class.
(I'd also recommend using "reference views" wherever possible to embed your
custom Views in other composite Views -- hold down the ALT key when you drag a
View from the resource list in the View Composer.)

    -- chris