|All blog entries are the opinions of the author and do not necessarily reflect the opinions of their employer. All the code presented is for explanation and demonstration purposes only. Any damages incurred to your site and/or data are not the responsibility of the author. Every effort is taken to ensure the code properly compiles, however sometimes there are some hiccups and you might be required to do your own debugging.
Signs You a Redneck Resizer!
Wednesday, July 25, 2012 8:35 PM
What are some signs you are resizing your forms wrong? (yes this is a bit of baiting the blog title :>)
This week I was asked to take a look at a scaling problem we have with our application. No big deal right, the “math” was juuuuuust a bit off. I was poking around and what I found reminded me tricks I used to do with VB. Hello! 1995 just called, they said to learn how to use a Grid!
Chances are you’ve created forms that had to resize or show/hide controls based on values or resolutions, right? Ok, did you EVER use this trick, put the datagrid or buttons you wanted to hide at the bottom of the page, then just manually resize the form to juuuust above the buttons so they would be hidden?! Well if you did, DON’T DO IT NOW!!!!!!!!!! DOH! NO NO NO! That’s a hack and no longer needed in the XAML world.
Hey, if you’re doing XAML development (Silverlight, WPF, WP7) then you REALLY should be learning how to use layout managers instead of these following signs “you’re doing it wrong” when it comes to scaling/resizing forms (or controls).
- The first sign is you’re seeing LOTS of bugs about buttons at the bottom of the page getting cut off half way. Or data grids not showing an entire row.
- You're setting an absolute height for your ViewBox. Doesn’t that just strike you as wrong? “Make this dynamical sizable object EXACTLY THIS tall.” Why are you using the ViewBox exactly?
- You see someone removing the “*” in the Width or Height properties. Maybe they’re even replacing them with Auto (they are related, but don’t have the same results, hint, one makes things smaller, one makes them bigger). Those two values are VERY much worthwhile knowing about!
- You're doing MORE work in code for resizing your page/control than it takes to drink that one cup of coffee (ie lots of *_LoadCompleted and *_Resized events)
- You see forever nested layout controls (StackPanels within StackPanels within…you get the picture), worse, they’re increasing in heights! DOH! What are you really expecting will happen?
- Your pages AND base classes have identical resizing code, everyone’s going it alone and nobody’s talking to each other. One work Overriding. The end results is a Rocky vs Clubber Lang fight, another hint, you’re NOT going to win!
- Setting heights/widths to magic values in code. That’s just so VB4!
- Looking on MSDN and complaining why you can find the .Show and .Hide methods! hint Visibility baby!
- You have some type of magic calculations for height/width calculations. Worse yet, you’re doing scaling math on values which are not changing on the screen or printer. Don’t laugh, I’ve seen this many times!
- You see magic constants for “fudging” or “adjustments”
- You are nesting StackPanels more levels than an Escher picture!
I worked at one place, it took two devs over two months to identify and fix scaling bugs (merging images of multiple bit depths, image resolutions, colour depths, screen resolutions, printer resolutions, oh ya, we had to account for print AND screen, oh my!). Both of us kept WISHING we were using XAML cause of the Visibilty property would have been SOOOOO nice! If you’re doing WPF or SL, you have it now! Use it!!!!
Now that you know some signs, AND you know to go look at the Grid (don’t be tricked into using StackPanel all over the place, it has it’s time and place, it’s not your hammer for your screws!) it’s time to grab a coffee and get coding!
Paul Sheriff: Understanding XAML Screen Layout
MSDN: Layout System