I am building an application and I would like the one of the forms to look like the control panel
Would you use a listview with groups?
thanks
No, I don't think you can make the ListView do this. At least not without rewriting its painting routines.
It isn't going to be easy to replicate this layout precisely in WinForms. There's nothing you can just drag over from the toolbox that is going to do it. It is possible, but it will take some effort.
What I would do, conceptually, is break it up into pieces. I count 8 different repeated "blocks". So I'd create a UserControl that models each of these.
Inside of the UserControl, I'd have a PictureBox control to display the icon, a Label control to display the heading, and a TableLayoutPanel that can be filled with the desired number of LinkLabel controls. Set all of the properties of the controls so that they match, and then write public methods to set the icon, heading, and add/remove links.
Then I'd drop a TableLayoutPanel onto my form, set the margins to have lots of whitespace, and add as many of those UserControls as necessary. At the top of the form, of course, you'd need another Label to display the heading/instruction text. Make the form's background white, and you're pretty much there.
The logic to switch between views isn't implemented, but consider whether you really need that. It is important in Windows because users are used to the old way of doing things. This doesn't apply to you.
Related
I am working on new WPF/MVVM project, where I see all most all controls are written for different needs, right from textbox to treeview. All are rewritten for simple need, for example, grid,stackpanel control are rewritten to add space between each item and textbox is rewritten to include label for it so that it has both label and text input are on itself.
My question : Is there any serious issue we would encounter because of this customization?
Already, I am seeing issues with aligning all controls, will i would see any more issues because of this?.
You should never create a custom or user control to add margins, a label to a TextBox, or a new ItemTemplate to a ListBox.
UserControls are for grouping frequently used combinations of controls into one reuseable control. An example may be a custom List-of-Values control that opens a dialog. This would be fine to implement as a UserControl.
Custom controls are good when a native control does not suit your needs. Say that you want to reimplement a DateTimePicker from scratch because the native one doesn't include milliseconds.
There are no serious issues as such, but you may find yourself maintaining all these controls for the next many years without there being a need to do so.
Settings Margins should be done in the View where you are using it, or on a Style in a ResourceDictionary.
This is of course only my opinion (and that of many others, I except), but if you find that the majority of your controls are 'customized' this way, you are doing it wrong.
Style and Templates rather than UserControls and custom controls.
The main issue is that you lose the ability to alter margins only in a single view. If you change your custom controls' inner paddings and margins, you will be changing all the views in your solution. If you use a style, you can always override it by defining a new style in the view, or by setting the property directly.
i am trying to create a wpf app and have different parts in user controls.
in the navigation i have some buttons (now using the ribbon ctp). is it possible to change the main user control when different buttons are pressed in xaml. or is this just a bad way to do things?
sorry, really new to xaml and im trying to get my head arround it.
Further to what Carlo has said,
The way we do it is to have a blank grid in the place you want your controls to all appear and then use BlankGrid.Children.Clear() and BlankGrid.Children.Add() to set up which control is visible in this position.
We found that was the nicest programatically as we have a large number of custom controls, but Carlo's method would work nicely if you wanted to use the designer.
I think this is a pretty regular procedure in WPF. In my experience, me and other programmers put the controls where we want to show them and make their visibility hidden, collapsed or visible depending on what we want to show the user.
I am adding user controls in my solution. The main page of my project will have a dock panel. When writing the xaml for my user controls should I remove grid and use dock panel or what? Iam using visual studio express and WPF.
The answer is it depends on what you want your control to look like.
Remember the Grid is to help you orgainze your controls. You can define features like columns widths, row heights, and other styling.
While a dock panel is to help dock your control to a part of the form or another.
So it depends on what you want your control to look like. You can nest a grid in a dock panel and vice versa. There is no set rule. It is really up to you.
Inside your user controls, use whatever type of panel makes sense for the contents of that control. In the main page, you set the DockPanel.Dock attribute on your user control, but that is independent of what's inside the user control.
It really depends on what you want to do.
Your top level may not even be a panel. For example, if you only want one control in the user control, then you really don’t need the panel.
Also, in some cases, even with composite controls, you may want to put something other than a panel as the top level control, for example, an expander.
Further, if you want to create a control that is very similar to another control, but behaves a little different, you may not even want to use a user control and instead inherit from an existing control. An example of this would be a numeric textbox that inherits from a textbox but adds keypress filtering.
When I drag a control from the toolbox on to the Visual Studio 2008 WPF design surface, it sets a margin based on where I dropped it and a default size.
Is there any way to prevent VS setting those? When I drop a control on a stackpanel I want it to flow in to the existing controls in the panel.
Thanks!
I've never found a way to prevent this. I just type the XAML instead.
EDIT:
I wrote the above nearly three years ago. In the meantime, it would appear that the design-time experience has gotten a lot better.
While the designer still adds hard-coded margins if you drag-and-drop, there are ways to remove those margins without having to do it by hand.
Here's a link to an article that illustrates how to use design tools in Visual Studio 2010 to lay out a form without having to type any XAML. (Despite the title, it's about WPF.)
The first part of the article shows hard-coded pixels, but I've linked to the second part that shows how to lay out the controls without that hard coding.
Layout Techniques for Windows Form Developers
When I drop a control into a stackpanel, it doesn't add margins, it "flows" in with the rest.
The controls you drop onto the design surface have a margin by default because that's how it knows where it's placed. What I typically do is create a grid and set it's margin where I want it, then create columns and rows to put controls into. I drop in my other controls which will add margins which are usually not what I want. After I have all my controls into my grid, reasonably placed, I switch to XAML view and either remove the margin completely (which causes a control like a button to fill the entire space), or make the margin something like 5, which puts some nice padding around the control.
Bottom line...and this is especially true with Silverlight development, you must get used to manipulating the XAML directly. It's the only way you'll get the layout exactly where you want it. This is my opinion and most everybody in my shop who does WPF/silverlight development.
Unfortunately there does not appear to be a means to do this.
The default size is set as a result of you manipulating the size of your control is the designer. When you increase the width and/or height of a control the designer is interpreting your actions as a request to make the control that specified width and/or height.
A similar situation is encountered with the margins. As you alter the position of your control within the designer, it modifies properties to achieve the layout you've created. In the case of most containers the simplest solution is to modify margins in order to achieve the desired position, as you've already pointed out the simples solution is not always the most desired.
Personally I prefer to only use the XAML editor and only occasionally take a peak at the WPF Designer when I want to see the current layout. I also tend to favor using the Grid to layout most of my windows/controls as it provides the greatest flexibility not only for sizing and positioning, but for other tasks/features such as animations, transforms, etc.
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.
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
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).