none
VisibleClipBounds returns always same value RRS feed

  • Question

  •  Hi everybody!

    I'm reading a book about programming Win-Forms from Charls Petzold (the german name is "Windows Programmierung mit C#" I don't know the english name).

    I know the book is using the Framework 1.1. I'm using Visual Studio 2008 and got a Problem with a Sample programm.

    Here the code of the Sample Programm:
    public partial class WhatSize : PrintableForm.PrintableForm  
        {  
            public WhatSize()  
            {  
                InitializeComponent();  
            }  
     
            protected override void doPage(System.Drawing.Graphics graphics, System.Drawing.Color color, int cx, int cy)  
            {  
                Brush brush = new SolidBrush(color);  
                int   y     = 0;  
     
                doIt(graphics, brush, ref y, GraphicsUnit.Pixel);  
                doIt(graphics, brush, ref y, GraphicsUnit.Display);  
                doIt(graphics, brush, ref y, GraphicsUnit.Document);  
                doIt(graphics, brush, ref y, GraphicsUnit.Inch);  
                doIt(graphics, brush, ref y, GraphicsUnit.Millimeter);  
                doIt(graphics, brush, ref y, GraphicsUnit.Point);  
            }  
     
            void doIt(Graphics graphics, Brush brush, ref int y, GraphicsUnit graphicsUnit)  
            {  
               GraphicsState gs = graphics.Save();  
     
                graphics.PageUnit = graphicsUnit;  
                graphics.PageScale = 1;  
     
                SizeF sizeF = graphics.VisibleClipBounds.Size;  
     
                graphics.Restore(gs);  
     
                graphics.DrawString(graphicsUnit + ": " + sizeF, Font, brush, 0, y);  
                y += (int)Math.Ceiling(Font.GetHeight(graphics));  
            }  
        } 
     
    The problem is, if I start the form all values are the same no matter how PageUnit is adujsted.

    Can anyone of you tell me if I make a mistake or if there is a bug in the latest .net-Framework?

    Regards
    Patrick Weegen

    Saturday, October 4, 2008 1:35 PM

Answers

  • This behavior is documented in this feedback article.  It is much too late now to get this fixed, it would be grossly breaking.  Which means you can depend on a workaround that scales from pixel units.
    Hans Passant.
    Thursday, March 26, 2009 3:15 PM
    Moderator

All replies

  • Looks normal to me.  What counts is how you interpret the returned rectangle size.  Say it returns 300x200.  When the PageUnit is Pixel, you'd have to specify a rectangle of 300 x 200 pixels to fill the visible clip bounds.  When the PageUnit is Points, you still have to specify a rectangle of 300 x 200 (now Points, not pixels) to fill it.  You'll get in trouble when you ask for the bounds in one page unit but try to fill it in another page unit.
    Hans Passant.
    Saturday, October 4, 2008 3:59 PM
    Moderator
  • Hi!

    I think you misunderstood me. The problem is not to create a rectangle to fill the visible clip bounds. The problems only occur by displaying the values.

    Maybe a Screenshot makes it clear.

    Regards
    Patrick Weegen.
    Monday, October 6, 2008 6:37 AM
  • I'm having the same issue. My interpretation of the MSFT docs is that the methods of the Graphics class work in terms of the PageUnit. If the PageUnit starts out in Pixel and VisibleClipBounds returns a 300x200 rectangle, I expect that changing the PageUnit to GraphicsUnit.Inch ought to make it return a 3.125 x 2.083 rectangle on my 96 DPI screen. Instead VisibleClipBounds still returns 300x200. If I interpret that in inches and draw a 300x200 rectangle, it'll cover the window, the screen, and my wall.

    Essentially the problem is that VisibleClipBounds always seems to be GraphicsUnit.Display units, even after you change the PageUnit. That makes it hard to determine how much real estate you have to draw on. If you know you're drawing on a monitor, you can manually convert using DpiX and DpiY. But for a printer (or presumably other devices) the unit is unspecified. MSFT says it's "typically" 1/100 of an inch, but what if it isn't? I've tried using 

    g.TransformPoints(CoordinateSpace.Page, CoordinateSpace.Device, pts);

    but that seems to return coordinates in a still-different system. In my case, it returns 1/600 of an inch on my 600dpi printer, but I hardly want to assume that's the way it always works. Any chance someone knows a more definitive answer?
    Thursday, March 26, 2009 2:17 PM
  • This behavior is documented in this feedback article.  It is much too late now to get this fixed, it would be grossly breaking.  Which means you can depend on a workaround that scales from pixel units.
    Hans Passant.
    Thursday, March 26, 2009 3:15 PM
    Moderator
  • Well, it's good to know I'm not totally misguided at least. Thanks for responding.
    Thursday, March 26, 2009 3:35 PM