locked
How do you turn a whole bunch of columns and rows into scrollview when snapped? RRS feed

  • Question

  • Exactly what the title says.  I have 100+ buttons each one in a separate grid.row grid.column.  In snapped view, they are automatically squished together.  I want to keep them in the same size but turned into scrollview so the user can scroll horizontally back and forth to find the button.  How?

    Sunday, September 1, 2013 10:06 PM

Answers

  • So you want the contents of your grid cells to be different depending on the screen state (e.g. some properties visible in the full view not visible when in s smaller, snapped state, perhaps hide the finer details when there is less screen real estate available)?

    It's hard to tell exactly what you want to do without seeing examples. The best approach depends on the specifics.

    Again, a gridview seems the most logical approach based on your descriptions. You set up two data templates, one for 'full view' and one for 'small view' (based on Windows 8.1, you'd switch to the small view when the app size dips below your preferred minimum). That way you can control how your info appears depending on the context. For example in some of my apps the snapped view displays a smaller, summarised view of the same info that is in the larger full-screen view, with text font smaller, less important details left out, etc.

    You could probably change the data template on the fly if you're hell-bent on not using a gridview. Set up the two data templates, then switch them around when the view is changed. I've never tried this myself (it's not a typical way of doing this sort of thing), but I see no reason why it wouldn't work. This approach will essentially be the same as creating a gridview, but with more maintenance (you'd have to manually change each box individually if you ever want to change the layout).

    You'll have to supply code if you want more specific answers. From the info given so far, gridviews with two different data templates using a scrollviewer when on a smaller screen area seems like the best option by far, and will achieve everything you have so far described; and it sounds like it would take a lot less code and maintenance than what I have inferred from how you've described your current approach.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Tuesday, September 3, 2013 12:28 AM
  • I agree with the answer above. It sounds like what you're looking for is a gridview which automatically takes available space into account and will rearrange your content accordingly when the app is put into snap view.

    Keep your head in the Clouds as you're coding .NET http://azurecoding.net

    Thursday, September 5, 2013 3:16 PM
  • Why don't you just put them all into a scrollviewer to begin with, then enable/disable the scrollbars as needed?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, September 6, 2013 3:09 PM
    Moderator

All replies

  • Are they set up using databinding or manually placed on the page?

    Can you provide a screenshot or describe their layout?

    Are these buttons laid out in a grid arrangement? If so I would recommend using a gridview rather than columns and rows, and bind your buttons using a data source ad template. Then you can set up a single data source that can fill your grid and also can fill a (separate) listview that you display when in snapped view.

    If you look through the samples (link at the top of the page) you will see how this works. You basically have two different layouts that get their data (your buttons) from the same source, and display the layout appropriate for your app's current view state.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Monday, September 2, 2013 7:30 AM
  • For reasons I really don't want to explain, gridview is out of the question.  Yes, they are manually placed on the page in a grid. 

    Is there no way to do what I asked?

    Added by edit.

    What the buttons are for are the elements of the periodic table.  The reason I used grids columns and rows is instead of gridview is because I need to preserve the shape of the periodic table.

    And no, what I'm working on isn't another periodic table.  Plenty of those around. 

    • Edited by RandyPete Monday, September 2, 2013 8:05 AM
    Monday, September 2, 2013 7:52 AM
  • Hmmm... it can be done, but it wouldn't be easy.

    You could simply set up a completely new page layout to display when in snapped mode, but that would involve recreating each button a second time (essentially you'd have two copies of everything, just laid out differently). When snapped you hide the grid and show the long list (which you could place inside a scrollviewer to allow for scrolling).

    You could also manually change the positions of everything when a screen layout change is detected, but that will take a lot of code (you're going to have to make changes for each of the hundred buttons individually), and would be really hard to change or tweak in future - you'll be hard-coding essentially.

    I can't think of any good reasons to not use a gridview. It automates exactly what you want to do, as far as I can tell, and it can be set up very quickly and easily (literally a few lines of XAML). Without knowing what you don't want to explain I'd still confidently assume that gridview/listview is a better starting point than manually placing controls in a grid even if you have to rework some other code to accommodate it.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Monday, September 2, 2013 8:13 AM
  • I did explain.  The control is a periodic table type control.  The order and positions of the buttons are extremely important.  Gridview changes those things when in snapped. 

    I'll keep playing around with gridview.  Thank you your for help.

    Monday, September 2, 2013 6:05 PM
  • A periodic table layout makes a gridview somewhat messy (I suppose you could leave certain values in your data source blank to allow for the places where no elements belong).

    Alternately you could take this approach (which is probably what I'd do):

    1) create a datasource of elements with all their properties (name, symbol, atomic weight, etc.)

    2) hard-code the data source into your grid manually (e.g. in the top-left column/row bind Elements(0), which would be Hydrogen rather than actually placing Hydrogen's details in the cell). Something like this in each cell (with appropriate element number):

    <Grid>
    <TextBlock Text="{Binding Elements[0].Symbol}"/>
    <TextBlock x:Name="AtomicWeight" Text="{Binding Elements[0].Weight}"/>
    </Grid>

    3) Create a separate listview, also bound to your data source, but the listview doesn't need to be hard-coded because you just want a scrolling list rather than an oddly formatted table.

    4) Detect a screen layout change and show/hide the list and grid appropriately


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Monday, September 2, 2013 9:42 PM
  • You don't understand.  I'm not looking to have a scroll through a list of the elements. 

    Just imagine it this way.  A periodic table fills up the whole screen in landscape.  When I snap, nothing has changed.  But instead of the whole table showing, only the first 3 columns or so are showing.  Then when I want to access elsewhere in the table, I could scroll right of the table. 

    It's like an x-ray scan.  You have the whole body.  The x-ray scans part of the body, say your feet.  Then you slide the scanner up and down the body to see the body.  The size of the body remains the same, but the view scrolls up and down to see different part of the body.

    Gridview will make a mess of the table.  What you are proposing will also make a mess of the table. 

    Monday, September 2, 2013 9:57 PM
  • Put the grid in a scrollviewer and that behaviour should happen automatically. The scrollviewer will probably have to be set up so that it stretches to fill the screen width (and therefore should resize when snapped). A bit of trial and error should get it working. I have an app that does this in portrait mode, and it worked automatically from memory.

    <Scrollviewer>
    <Grid>
    <--! all your elements laid out here !-->
    </Grid>
    </Scrollviewer>

    Using a hard-coded grid will make this difficult as you will probably have to do a lot of calculating to get it to fit correctly (don't forget all the different screen sizes and resolutions you'd have to cater to).

    I'd still personally go with a gridview and use 'blanks' to effectively hide the spots where no elements belong (e.g. 16 blank items between Hydrogen and Helium). Then everything after setting up the data source is very easy to manage. If you hardcode the grid make sure you are prepared to potentially change all 100+ items every time you need to tweak your UI or fix a bug, and test it thoroughly on different screen sizes. Windows 8 supports a wide range of screens, and they are not all the same ratio/shape. It can be very tricky to get hard-coded UI to work correctly on different screens.

    The benefits of a gridview:

    • You can control the cells with a data template very simply (and only once)
    • You can change element details (e.g. fix typos) in your code rather than XAML
    • Changing the layout to fit different screens is not necessary (however you will need to ensure the full table is visible on all screens at a good size)
    • Scrolling behaviour/rendering time is probably going to be better by using built-in functionality (more optimized)
    • Event handlers don't need to be created for each element, just for the gridview itself (e.g. no need for 100+ event handlers for tapping on each element, just 1 'element_grid_tapped' event)

    I personally wouldn't leave the same layout in snapped view. It's not what I'd consider as good UI, nor what I'd expect as a user. But you know your app best. Scrolling left/right in snapped view is a poor experience, and may even be against guidelines. Note that all the good apps treat snapped view as a vertical layout.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Monday, September 2, 2013 10:15 PM
  • I'm accounting for 8.1's snapped view.  It's not the same as 8's snapped.

    I've already written my code to compensate for all screen sizes out there.  I've tested my code with 3 different screen sizes, including the MS surface.  put everything in scrollviewer.  We'll see what happens :-)

    Monday, September 2, 2013 10:35 PM
  • Here's the problem.  Like I said before, the periodic table isn't the main content of my app.  There are plenty of periodic tables out there.  My app is a lot more expansive than that.  The periodic table is a control.  In other words, within the grid there are a lot more stuff.  I don't want some contents to be in the scrollviewer.  Unfortunately, I can't just put <scrollviewer></scrollviewer> around a bunch of buttons.  I have to encompass the buttons with something.  <Border> doesn't work.  Is there an xaml code that I can use to bunch a group of buttons together?  Definitely not stackpanel because these buttons are columned and rowed.

    Monday, September 2, 2013 11:54 PM
  • So you want the contents of your grid cells to be different depending on the screen state (e.g. some properties visible in the full view not visible when in s smaller, snapped state, perhaps hide the finer details when there is less screen real estate available)?

    It's hard to tell exactly what you want to do without seeing examples. The best approach depends on the specifics.

    Again, a gridview seems the most logical approach based on your descriptions. You set up two data templates, one for 'full view' and one for 'small view' (based on Windows 8.1, you'd switch to the small view when the app size dips below your preferred minimum). That way you can control how your info appears depending on the context. For example in some of my apps the snapped view displays a smaller, summarised view of the same info that is in the larger full-screen view, with text font smaller, less important details left out, etc.

    You could probably change the data template on the fly if you're hell-bent on not using a gridview. Set up the two data templates, then switch them around when the view is changed. I've never tried this myself (it's not a typical way of doing this sort of thing), but I see no reason why it wouldn't work. This approach will essentially be the same as creating a gridview, but with more maintenance (you'd have to manually change each box individually if you ever want to change the layout).

    You'll have to supply code if you want more specific answers. From the info given so far, gridviews with two different data templates using a scrollviewer when on a smaller screen area seems like the best option by far, and will achieve everything you have so far described; and it sounds like it would take a lot less code and maintenance than what I have inferred from how you've described your current approach.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Tuesday, September 3, 2013 12:28 AM
  • I agree with the answer above. It sounds like what you're looking for is a gridview which automatically takes available space into account and will rearrange your content accordingly when the app is put into snap view.

    Keep your head in the Clouds as you're coding .NET http://azurecoding.net

    Thursday, September 5, 2013 3:16 PM
  • I don't want anything to rearrange.  that's the point I've been trying to make.  I want everything to stay where they are when snapped.  I want their sizes to stay the same.  Ive been playing around with gridview and it is not what I'm trying to do at all.
    Thursday, September 5, 2013 5:08 PM
  • Why don't you just put them all into a scrollviewer to begin with, then enable/disable the scrollbars as needed?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, September 6, 2013 3:09 PM
    Moderator