A graphic base question

Hi,

I try to set up my Dolphin grahic base classes-objects-functions.

I create an MPV component, where the view (sometimes doublebuffered)
probably embedded in scrolling decorator.

Can I set up the size of that specific canvas initially?

Thanks,
Janos

Well,

I mean the size of the canvas looks changing dynamically if I use
vector graphics operations, and after resizing the main shell window.
Even in the Scribble you can draw strokes out of the window bondages,
and after resizing you can see the parts, which were earlier out of the
"canvas original visible size". But I would like to control the size,
like in some paint programs I can tell: "I would like to create an
image with 400@300 pixels. And if the drawer would like to draw bigger
graphics, then he/she needs to start with a new empty image of the size
big enough.

Not to speak about the zoom functions, where you land at a "viewport"
showing only a part of the canvas.

How can you follow which portion is visible, when you can minimize,
maximize, resize the containing shell window, and the "subview" size
seems to follow it.

Any hints would be appreciated in this direction.

Thanks in advance,
Janos

Janos Kazsoki wrote: First off, let me say that I don't know if any of this is going to be
helpful, or if the way I am doing things is the best/brightest/easiest
way to do things. I will simlpy say, I have had run into the issues yuo
are talking about and I have solved them in a way that is acceptable to
me from a coding and performance point of view.

Simply put, I keep track of all the variables that sit behind the scenes
so that I can manually eliminate the problems you are experienceing. If
you know where the mouse is, relative to your original graphic, the
scaling, or the amount of the image that is visible in a window, become
irrelavent.

For example - I have a program which lets users zoom into, select from
and crop digitial photos or other graphics. Inititally, I show them the
graphic, scaled into a window that opens at a defualt physical size.
When that winodw opens, I know, based on the size of the image and the
size of the canvas, how much the image is being scaled. I hook the
window sizing events so that if the user drags the window larger or
smaller, I can recalculate the factor that the image is being displayed
at. Again, I might be able to pick this up from the widget displaying
the image, but I include a blank border around the image (for other
reasons), so it's just easier for me to do it this way.

Knowing the degree to which the image is being scaled, allows me to map
  the screen location of the cursor to the corresponding point in the
actual image. That way, if a user selects and area of a compressed image
to zoom in on, I can display the area in question from the base image.
This is better than simply maginfying what is on the screen, as it
allows the rendering window to take advantage of the greater detail
available from the raw image.

I also hook the mouse movement and mouse action events, to update a
series of  variables. By trapping these events, I know if the user is
moving beyond the edge of the image, and into the buffer zone I wrap the
image in. I also use this in another way. For cropping digital photos,
the user can specify that the selected area or area of interest,
maintains the aspect ratio of the original photo. So when the user
starts dragging a selection rectangle, I can recalculate what it "should
be". If the user has the window set to scroll around the full size
image, I can control the scrolling during their selection. So they can
start a selection, drag it up against the right side, and I can start
scrolling the image to the left in the window underneath their
selection. I can also figure out when they've reached the "edge" of the
underlying image, and prevent them from selecting anything beyond that.

IMO, the easiest way to deal with the issues you have encountered is to
keep track of: What's visible in the window, the scale factor of the
display, where the mouse is and the other mouse events (movement, button
action, button poistionm, etc.). If you know those variables at all
times, you can figure everything else out.

I hope this helps,

--Dan

---------------------
Daniel Antion

Janos Kazsoki wrote:

> How can you follow which portion is visible, when you can minimize,
> maximize, resize the containing shell window, and the "subview" size
> seems to follow it.

Adding to Dan's response...

It depends on how sophisticated you want/need to be, and also on how big your
images are.

If the images are reasonably small (less than, say, 3000x3000 when zoomed) then
you can simply create a bitmap of the relevant size, and use an ImagePresenter
to display it, with a ScrollingDecorator wrapped around it to handle the
scrolling.  The scroller uses the contained view's #preferredExtent to decide
how big the view would "like" to be, so if you set that (and set
#usePreferredExtent to true) then your user will be able to scroll around a
space as big as you've asked for.

If you want more sophistication, or if your images are too big to handle by
that method, then you'll have to take charge of the scrolling yourself.  You
can create a bitmap that is the same size as your display window, and then keep
track of the scroll positions (and zoom factors) to update the bitmap from your
"real" data.

There are two ways to do your own scrolling.  One is to use your own ScrollBars
(the 'scroll bar' view resources of NumberPresenter).  I have never used that
myself, so I don't know how easy that would be; it doesn't /look/ too hard.
The alternative (which I have used) is to turn on the WS_HSCROLL and WS_VSCROLL
bits in the view's #basicStyleMask -- unfortunately you then have to do a fair
amount of messing around to tell windows what the scrollable ranges are, handle
scrolling events, and so on...

[ Previous paragraph was a direct quote from about a month ago --
apologies to anyone who's feeling a sense of deja View ;-) ]

    -- chris

Dan, Chris, (and prometheus...)

I was afraid there was no royal way to do that...

But now the #toBeDone is much more clear.

Many thanks,
Janos