tags:

views:

439

answers:

2

So I'm just starting out with WPF, and I'm really annoyed by the fact that if I lay two Grids on top of one another, the top Grid isn't opaque. It makes designing extremely annoying. Can this be turned off somehow?

I'm just building your standard Winforms STYLE application, but in WPF. I'm just trying to start bridging the gap here. In Winforms(and VB) you'd always have group boxes or something on your form, and then depending on some user context, one of those group boxes would be on top. Its how I've designed forms since time immemorial. One of two things must be true here:

A) This is not the recommended way to design Windows going forward with WPF, but I don't understand what you're supposed to do

B) There is some property to make the Grids opaque so I can build the Window in the style that I'm used to.

I'm fine with answers that solve either A or B. If I'm not doing things the right way because they've changed, then please enlighten me.

Update: So it turns out, I can make the grid opque by setting the background color, but now it seems like I'm locked into a White background as opposed to sticking with the system colors.

+2  A: 

You could use SystemColors to make the control background colour match (rather than being white).

I don't understand why you want to put one grid on top of another though. In WPF you generally use a single grid to stack multiple visual elements within one region. Can you explain why you want to hide things in the background with foreground elements?

It sounds a little like you're implementing a tab control -- switching between pages of controls depending on focus. Have you experimented with the new TabControl?

I'm moving from WinForms to WPF development wherever possible and have found that in doing so it's taken some readjustment. WPF has a completely different way of laying things out and now that I'm more comfortable with it, I think it's superior. I'm guessing you just need to ride the learning curve a little longer.

Hope that helps.

EDIT: In response to your comment, I imagine you can have a tab control without tabs, though I haven't tried it myself (might be worthy of another question on SO). Tab controls are headered controls, meaning that they have a header item and a content item. In this case, the header is the tab button, the content is the page item. You can specify a ControlTemplate that details how these items should be displayed relative to one another.

Interestingly, many other types of common GUI element are also headered controls:

  • Menu items - The menu item text/icon is the header, and the optional submenu is the content
  • Tree view - Each node is the header, and optional children are within the content
  • Group box - The header is, well, the header and the content is, well, the content :)

Note that in the case of menu items and tree views, the type may recursively nest within itself. This is quite elegant and can give some wildly different presentation options over the same logical model with only changes to the control template.

For more information read about HeaderedContentControl and HeaderedItemsControl

Drew Noakes
Can you create a TabControl without the Tabs? In terms of functionality, it is like a tab control, but which tab the users sees is actually based on context.Its your standard windows explorer style application, tree view of objects on the left, content pane on the right.
Jonathan Beerhalter
A: 

You could use the following:

  <Grid Background="{DynamicResource {x:Static SystemColors.WindowBrush}}">  
  <!-- content -->
  </Grid>

This will respond to changes in the system colors on the fly (the DynamicResource does this).

dpp
Use StaticResource for reduced overhead with the downside that your application won't update if it's running while someone changes the system's colours.
Drew Noakes
This is one of the cases where DynamicResource is applicable while I agree with you that Static is usually to be preferred.
dpp