Another issue, apparently similar but separate to the other issue.  This time a similar problem exists as when the selection sometimes jumps to the origin...

Any thoughts?

url: http://www.flickr.com/photos/78608814@N00/92871873/

Thanks,

The 10 issue seems the most likely for the first problem, and I've found zoomtorect (stupid mistake on my part...)

I am using groups, so that is probably the cause of the selection problem.

But the second example here the size is reasonable, but the zoomtofit starts at the topleft anyway...  Also I seem to have had some similar thing where the actualy rect coords seem to be ignored with similar behaviour (maybe this is another result of the 10 limitation as the vertical distance seems to be the same as the limited distance in the first example -- i know this isn't very coherent, sorry.)

Thanks, that did solve the problem, except for one 'untidiness' (not a real big issue but looks weird.)

In the new image (http://www.flickr.com/photos/78608814@N00/93799777/) you can see that the bottom of the zoom window goes below the page.  This was happening in the previous version as well, but the width was restricted by the limit.  This appears to happen irrespective of the shape of the page once it is super-landscaped enough.

I have stumbled on another problem though (might be related, it's definitely a scale issue.)  I call:
     flowChart.PrintOptions.ScaleToPage();
     flowChart.PrintPreviewEx();
and get the result in the image (http://www.flickr.com/photos/78608814@N00/93799777/)

It doesn't appear to do any scaling at all (the whole print run is about 100pages!) but when I explicitly scale the image using .Scale = 2.0F for example, it displays fine.

Also, the scaling in the toolbar doesn't appear to work (as I meant to implement these signal myself in some way?)  That is the landscape button does nothing, and the scale menu does nothing also.

On a related note.  Although I have no control over the scale of the incoming symbols, it would be possible for me to scale them down and then back up on-the-fly.  Is this something you would recommend (given the GDI+ bugs you mentioned.)  If so, what type of algorithm would you recommend -- I can't wait until everything's arrived to display, so anything related to total height/width isn't really useful.  I'd have to work off the first or first few elements and make a judgement based on that.

Thanks for you quick response on the other problems.

Paul.

Actually that last dll did not include a fix for calculating wrong bounds for groups, the developer that fixed it hadn't checked in his changes when we uploaded the dll. So after calling ZoomToFit, the viewport likely starts from 0,0 instead fo the real bounding rectangle of the items.

The Overview window displays the whole document area (DocExtents) and not only the area that contains items, that could explain the untidiness.

Stoyan

I guess there is no need to scale the symbols up. The pen problem I have mentioned happened only with dashed pens whose width is > 0 and when the ZoomFactor is a very small one, say 0.XX. If pen.Width is 0, GDI does not scale the lines drawn with that pen up or down, but always creates 1 pixel -wide lines. So if you use solid pens or pens whose Width is set to 0, there should not be problems with that.

The Graphics.DrawString bug can happen only if you use custom drawing. When we implemented the Overview control we put checks around all DrawString calls, so it is not called when the scale is very small. Otherwise the Overview constantly crashed without those checks. So if you call DrawString from a DrawBox event handler, put that in an "if" statement that checks the ZoomFactor.

Stoyan

Stoyo,

At the end of this message is the information you asked for.

I've also attached a set of images from my application (http://www.flickr.com/photos/78608814@N00/) that show the weird docextents/zoomtorect behaviour, using the latest dll's from you.  The scaling is performed using the following code, which I believe to be correct:

    public void ZoomToVisible()
    {
     float minX = Single.MaxValue, minY = Single.MaxValue;
     float maxX = -Single.MaxValue, maxY = -Single.MaxValue;

     bool foundVisibleObject = false;

     foreach (Box box in flowChart.Boxes)
     {
       if (box.Visible)
       {
         foundVisibleObject = true;
         if (box.BoundingRect.Left < minX)
           minX = box.BoundingRect.Left;
         if (box.BoundingRect.Top < minY)
           minY = box.BoundingRect.Top;
         if (box.BoundingRect.Right > maxX)
           maxX = box.BoundingRect.Right;
         if (box.BoundingRect.Bottom > maxY)
           maxY = box.BoundingRect.Bottom;
       }
     }

     foreach (Arrow arrow in flowChart.Arrows)
     {
       if (arrow.Visible)
       {
         foundVisibleObject = true;
         if (arrow.BoundingRect.Left < minX)
           minX = arrow.BoundingRect.Left;
         if (arrow.BoundingRect.Top < minY)
           minY = arrow.BoundingRect.Top;
         if (arrow.BoundingRect.Right > maxX)
           maxX = arrow.BoundingRect.Right;
         if (arrow.BoundingRect.Bottom > maxY)
           maxY = arrow.BoundingRect.Bottom;
       }
     }

     float width = maxX - minX;
     float height = maxY - minY;

     if (foundVisibleObject)
     {
       flowChart.DocExtents = new RectangleF(minX - width * 0.05F, minY - height * 0.05F, width * 1.1F, height * 1.1F);
       flowChart.ZoomToRect(new RectangleF(minX - width * 0.05F, minY - height * 0.05F, width * 1.1F, height * 1.1F));
     }
    }

Which basically zooms to visible items +5% border.  I am setting docextents at the moment here only as a test to work out what's going on...

In _a through _d you can see the slightly weird but not major problem of too thin but too high in the zoomtorect (the docextents seems to always work as expected, as does the actualy visible chart.)

_e and _f however really show the problem, in _e the visible-area marker in the overview window is missing completely!  In _f I have clicked on the overview panel, and a visible-area marker appears (but without the black boundary) but it has nothing at all to do with what is visible...



-

flowChart.DocExtents
{X = 208.063919 Y = -232.671387 Width = 3968.19653 Height = 871.274841}
System.Drawing.RectangleF


Bottom
638.603455
float


Height
871.274841
float


IsEmpty
false
bool


Left
208.063919
float
+

Location
{X = 208.063919 Y = -232.671387}
System.Drawing.PointF


Right
4176.26025
float
+

Size
{Width = 3968.19653 Height = 871.274841}
System.Drawing.SizeF


Top
-232.671387
float


Width
3968.19653
float


X
208.063919
float


Y
-232.671387
float
+

Static members

+

Non-Public members

-

doc.DefaultPageSettings.Bounds
{X = 0 Y = 0 Width = 827 Height = 1169}
System.Drawing.Rectangle


Bottom
1169
int


Height
1169
int


IsEmpty
false
bool


Left
0
int
+

Location
{X = 0 Y = 0}
System.Drawing.Point


Right
827
int
+

Size
{Width = 827 Height = 1169}
System.Drawing.Size


Top
0
int


Width
827
int


X
0
int


Y
0
int
+

Static members

+

Non-Public members

Just to be sure I understand.  You're saying that in _a throug _d the preview is constrained by the relative dimensions of x and y?  If that is correct, the how in each of these is the x:y ratio different, in _d the visible area indicator is portrait?  Also, particularly in _c and _d, the visible indicator light blue area in the overview window has no bearing at all on the visible area in the flowchart.  Clearly in _d the visible area is only half as wide as the screen.  Also, the height of the view window relative to the page is identical in each of the views, always about 15% of the height of the page.

I understand that as far as I can tell you are using a zoomfactor internally.  If this is the case then obviously it is not possible to keep the exact rectangle zoomtorect requests.  However there does appear to be an issue when the indicator has no bearing on what is actually displayed.

The docextents you asked for:

_b: +flowChart.DocExtents{X = 246.7052 Y = -224.59639 Width = 3118.08838 Height = 693.6248}System.Drawing.RectangleF
_c: +flowChart.DocExtents{X = 283.890625 Y = -224.59639 Width = 2300.009 Height = 693.6248}System.Drawing.RectangleF
_d: +flowChart.DocExtents{X = 310.030029 Y = -224.59639 Width = 1724.942 Height = 693.6248}System.Drawing.RectangleF
_e: +flowChart.DocExtents{X = 353.362 Y = -219.1214 Width = 771.639 Height = 573.1748}System.Drawing.RectangleF
_f: +flowChart.DocExtents{X = 353.362 Y = -219.1214 Width = 771.639 Height = 573.1748}System.Drawing.RectangleF


I've tried these dll's, and there's no obvious difference.  The programmatical scaletopage has no effect, and the landscape and scaling buttons on the printpreviewex form have no efffect.  Here's the code I'm using to call the print and printpreview:

    internal void PrintPreview()
    {
     CropPageToVisible();
     flowChart.PrintOptions.ScaleToPage();
     flowChart.PrintPreviewEx();
     CropPageToAll();
    }

    internal void Print()
    {
     CropPageToVisible();
     flowChart.PrintOptions.ScaleToPage();
     flowChart.Print();
     CropPageToAll();
    }