4

Windows Store app written using C#/VS2013.1

I have wrapped up a complex Grid/StackPanel arrangement with buttons, images, checkboxes all inside a Viewbox tag like below:

<Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="*"/>
            <RowDefinition Height="8*"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
            <ColumnDefinition Width="8*" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Viewbox Grid.Row="1" Grid.Column="1" Stretch="Uniform">
          <Grid>
          ... (lots of nested elements)
          </Grid>
        </Viewbox>
</Grid>

The goal is to dynamically scale the page, leaving ~10% border along each edge. I've tried running this on different resolutions and devices, and everything looks perfect.

My question is, is there a downside to using Viewbox to wrap up complex/nested elements this way, versus painstakingly planning and coding width/height/font in each element so that they scale up properly to whatever resolution the app is being run on? I read some posts suggesting that Viewbox should be used only when other methods fail (or designer didn't consider scaling when XAML was first written). Is there a reason to that?

JJLL
  • 374
  • 4
  • 13

1 Answers1

3

If the "lots of nested elements" are designed without fixed width scaling in mind, the Viewbox would be unnecessary, as the Grid will automatically fit 80% width/height if you set it to stretch to its container. Adding unnecessary layout elements will only increase the rendering time requirements for your application, which is the primary disadvantage here.

However, if the content is full of "fixed sized" elements (ie: you have hard coded widths or heights, etc), then this will provide you that scaling quickly and easily. Given that this displays exactly as you want, I would leave it unless you find some specific issue with your current solution.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Thanks for the reply! I have a combination of fixed/flexible elements, plus fonts that need to be resized if their corresponding grids became larger, so it would be extremely tedious to code that without using Viewbox. – JJLL Mar 11 '14 at 22:34
  • @JJLL In that case, I'd just stick with ViewBox - if it works, and gives you adequate perf, why try to rock the boat? Is there a specific concern that's bothering you? – Reed Copsey Mar 11 '14 at 22:38
  • I'm trying to find out if I can stick to this usage model for future XAML pages. I applied Viewbox after having failed to consider scaling when coding this particular XAML page, and I want to figure out what advantages/disadvantages for using Viewbox vs. coding native flexible sizes in XAML. – JJLL Mar 11 '14 at 22:43