Re: question on maximum width/heights
From: Gerald Hernandez (Cablewizard_at_spam_remove@Yahoo.com)
Date: 02/27/05
- Next message: Joergen Bech: "Re: Making a Startup Windows Form Invisible"
- Previous message: smith: "Re: question on maximum width/heights"
- In reply to: smith: "Re: question on maximum width/heights"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 26 Feb 2005 22:47:49 -0700
Yeah, I had forgotten about the failures that occur far below the
theoretical maximums of the Int16. Sometime in the last year I think I saw a
discussion on this topic in the microsoft.public.dotnet.framework.drawing
group. Someone posted what seemed to be a reasonable explanation for why it
chokes at those various levels, but I can't seem to locate the posts at the
moment.
IIRC it has something to do with other address limits. Such address pointers
across the whole bitmap with padding can't exceed a certain number. And if
you look at your sample numbers, you are flirting with the 1GB range.
I didn't know it was a fatal error. However, in this case I'm not surprised.
I wouldn't be pleased, but it wouldn't surprise me.
Gerald
"smith" <rcsTAKEOUT@smithvoiceTAKEOUT.com> wrote in message
news:Y9aUd.6526$MY6.5236@newsread1.news.pas.earthlink.net...
> Thank you gents, you both put the information in a very clear way.
>
> I do realize that using such large values would not give useful results
and
> it was the mid-level explanation that you gave, rather than a workaround,
> that I was looking for.
>
>
> Just a side-mention of a related minutia: Even the Int16 "adjustment"
isn't
> good enough to protect against an un-handleable exception when
> programmatically resizing any GUI control. If you give it a fast test
> sometime you'll be amused or annoyed to see that on a 4:3-native monitor
at
> 32bit color depth the maximum size you can set a control is a square at
> 16095x16095 while 16096x16096 will crash your app. And, with no obvious
> logic, the non-square maximum is 16228x15964 - values set to either
> dimension, it doesn't matter -with 16227x15965, 16226x15966, 16225x15997
and
> so on crashing your program. If you're using a 4:3-native display at
> 16bit then you can get a 22762 square result (22763 being the killer) and
> the non-square dimension limits are similarly off-kilter.
>
> These values all come from XPPro machines but the tests were done on
several
> boxes from AMD-M 1Ghz with 16MB shared video ram to 3.2HT P4 with ATI
> Radeon 128MBdedicated and the thresholds seem to hold up the same all
> around. I also have test numbers on 1440x900 widescreen displays (the
> fastest growing niche in laptops) and those results are even more
illogical.
>
> I think you get the idea: If these aren't magic numbers then they may as
> well be. ;-)
>
> Oh, and it is an "Unhandle-able" Exception. If you try setting a
picturebox
> or button or listbox or any painted control to sizes greater than those
> mentioned above you'll get a
> System.ComponentModel.Win32Exception just after setting the properties.
You
> can use a try-catch to pass the information along to a user, but once they
> hit OK on your message and the code returns the app will immediately die
an
> ungraceful death. There's no way to stop the application from crashing
once
> the width and height have been specified (and as far as I can tell it's
just
> plain impossible for .Net to figure out in advance what IS a truly safe
> maximum size without using these magic numbers.)
>
> Again, thanks for your taking the time on my Int16/32 trivial quandry...
and
> if you happen to see some pattern in the numbers above I hope you'll let
me
> know because while I know it can't be random, it sure seems pretty random
to
> me. :)
>
> All the best.
>
> Robert Smith
> Kirkland, WA
> www.smithvoice.com
>
>
- Next message: Joergen Bech: "Re: Making a Startup Windows Form Invisible"
- Previous message: smith: "Re: question on maximum width/heights"
- In reply to: smith: "Re: question on maximum width/heights"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
