When building WPF forms that are used for data entry (e.g. A bunch of labels next to a bunch of textboxes and comboboxes) I've seen two methods:
Create a master Grid, divide it into two columns, and add rows with Height="auto" for each field and two rows for header and footer (and submit button), and each label and text box has their own row.
The other method is to create a master stackpanel and inside it a horizontal stackpanel for each pair of label-textbox.
How do you design your data entry forms? I'm currently torn between the two methods, maybe there's an alternative that I'm unaware of?
EDIT: Henk said I should define best and I think I agree, by best I mean easiest to maintain, create, align and add or remove fields from as demands change.
So far the only criteria by which the grid is better is ease of alignment.
definately first method!
it's well aligned, especially with the use of SharedSizeGroup so you can have the same alignment eg in different Groupboxes.
I have used both and it really depends upon how your form is going to look. If you have a really simple layout where you are going to have labels and and corresponding fields of approximately the same size then your first method works well. It lets you create two columns that line up very well. However, if your fields are of varying withs, and heights and you want to be more complex with the layouts then a hybrid approach may be best. If you are doing anything more complex than just labeling fields on basic controls you may want to create user controls rather than just using what is there out of the box. When laying out fields in both a horizontal and vertical jagged manner it becomes hard to maintain the grid layout as you have to wind up having a grid with lots of columns and rows. The fields and labels have to span columns and rows to get your alignment correct. This works, but is a nightmare if you ever want to reorganize the form.
For what you wrote, it sounds like the first approach is best. If its simple now and some point in the future it becomes more complex, its easy to change. However, if you have a more complex layout already then a pure grid based approach probably isn't best.
Disclaimer: I am going to say little about my own company's product in my blog that gives comparison and challenges in maintaining forms.
Both Grid and StackPanel have Maintanence nightmares so we went on different approach of creating Form Layout, and I have outlined our approach here on this link,
http://akashkava.com/blog/296/advanced-data-form-with-ui-atoms-on-wpf-and-silverlight/
Related
I've got a massive UI that I'm designing. The way that my employer wants it, there are at least 100 labels. Now, I've always thought that in cases like this, breaking up the UI into smaller custom controls was the ideal way to go. However, someone recently told me that custom controls are really only for code re-use. What is the actual suggested practice for this?
EDIT
The finished form will look like this:
Now, I'm using WPF for the UI, and I'm thinking of breaking this down into smaller bits.
Based on your image i see some repetitions, each of this repetitions could be a custom UserControl
But it depends on the usability is it easier to write a custom UserControl so do it but if it would reduce the readability of your code and it also adds additional complexity don't do it
here are an example of what could be separate UserControl's
the green ones are possible useful encapsulations of logic
the orange ones maybe need some not market stuff (don't know enough about your software)
the red ones are the maybe's based on the intern use (from the visual part they are repetitions so the should custom UserControl)
Since your UI is read-only, I'd suggest using a grid.
Are you new to WPF? To break the View into bits WPF offers you CustomControls and UserControls. They are two very similar things yet completely different from each other. CustomControls are Buttons, Labels, TextBoxes, DataGrids...etc. They are basically simple stand-alone controls. UserControls are groups of stand-alone controls serving a purpose such as example a Button and a ComboBox next to each other so user can select something in ComboBox and confirm that by clicking the Button.
If you wish to display data from database I suggest you DataGrid which will give you a table-alike look with rows and columns and all that. If you wish to place few buttons next to DataGrid on which the user may click to insert a new row or to edit a certain cell then I suggest you to wrap all that with a UserControl which you can reuse in other places where you have to display and change data from database too.
You should be using a datagrid and can customize its template to render individual cells as Textblock (lighter version of Label) from a rendering perspective. The main difference between Textblock and Label is very minor things such as access keys and disabled state behavior. But from a WPF object hierarchy - Textblocks are much lighter. But besides that point - from your employer perspective - once you have customized the grid template and render them (so as they look as textblocks/labels) - your employer should have no problems.
Also as somebody suggested above - if you want to logically break sections of the UI since they maybe coming from a different table in db - then User controls is the way to go (for maintainability of code)
Let me know if you are looking for more technical details or need help further technically.
There is nothing wrong in making and using custom controls or user controls or defining some data templates which will be reused depending on how your data is organized.
For sure the UI looks pretty messy and some sort of grid should be used with templates for example where there is similar data. I also have the suggestion and first think about the data and the functionality before starting and let the UI be driven by that. For sure you will the reuse controls/templates. If you think in front on the model and behavior the UI can afterwards more easily changed.
Create your viewmodel correctly, implement the functionality in commands, use bindings, after that the UI will come naturally, reuse controls, use several grids, make the UI more user friendly using several regions, tabs, windows or anything that makes the user more comfortable.
I got a pretty big form on a wpf page. I'm putting it together on a Grid, but all the element clutter the page. I figured i'd split out the form into smaller usercontrols and then piece it together on the page as one form. That didn't quite work: SharedSizeScope on a Grid makes the form 'dance'
I could break up the form into a 'wizard style' page, with a next button - dealing with each user control on its own, but i'd rather not break it up into several pages because the end user is used to having it all on one page. Also the validation/storing of data is really a big-bang operation, making it harder to provide feedback if something goes wrong in one of the first pages/usercontrols.
So what now? I'm really tempted to just put all the small elements directly on the page in one big grid. I just feel it's wrong - it will be a maintenance nightmare - i even started thinking 'i wish there were some kind of #region tag in xaml' - that means i know i'm wrong ;)
What can i do?
I would strongly recommend to use nested container controls, like Grids (or other Panels) inside other Grids inside more Grids etc.
It is very common to have several nesting levels, and thus hierarchically split a complex layout into multiple less complex sub-layouts. This makes your layout significantly simpler compared to one big container that tries to do it all (see your failed ShardSizeScope approach).
Once you have created a sensible hierarchy of containers, you may easily use the Visual Studio XAML editor's code collapsing feature to keep track of all your XAML.
I'm working on a new project where the design calls for dynamic rows and columns displayed in some form of grid. I think I can accomplish this very hackishly using the plain ol' Grid, but it seems like it should be possible using a "real" grid.
In my mockup, I circled the tricky bit in red. Under column 1, I have effectively 2 columns of data. The problem is the fact that my data in column 1 can span multiple rows. And the fact that column one is really two pseudo columns and each one can span a different number of rows independently. Note: the data is fake and inconsequential. I'm open to ideas for a good implementation. I can fall back to the Grid and do this all in code behind, I'm open to purchasing a datagrid that may have more power than the DataGrid and my absolute last resort/preference is to restructure this format to something a little more doable.
Thank you for any ideas you can provide.
Most commercial WPF DataGrid implementations handle hierarchical data like this. For example, Telerik's DataGrid (part of RadControls for WPF) supports hierarchical data in multiple formats.
Typically, the default styling is a bit different than yours above, but can be adapted to that format via styling.
I am new to WPF environment and I am experiencing some problems like if there are alots of things how do we manage them.for example I have three borders each of same size same location and they contains controls like textboxes etc etc we construct them sequentially but when it comes to edit we get in trouble modifying the border that is at bottom.
So in short how do we manage many controls on single page so that it remains easy to edit
Not sure I completely understand your concerns, but here are several point that make editing WPF UI pretty easy:
Correct usage of layout panels. If you will use approach with absolute positions for each control then it might become a nightmare to move or resize some of your controls. Correct layout (and panels such as DockPanel/StackPanel/etc) might help you a lot.
Incapsulating repeatable parts. WPF has a lot of feature to avoid repeating UI code. I'm talking mostly about Styles and Control templates at the moment. If you have your borders repeating through the entire window, maybe you should think on extracting this border as a ControlTemplate for ContentControl for example?
but I've found that encapsulating controls such as borders, textboxes etc in User Controls helps to keep things well managed (not to mention helps reduce code), similarly using a Resource Dictionary to store styles/animations is useful for very big projects (remember though that the local resources will take precedence when applied so remove them if they not in use)
furthermore, using Layout Panels such as Stacks,Grids and Dockpanels allows you to collapse User Controls when not needed or otherwise (also I've found that for some reason, Grids allow controls to overlap (when items are not correctly ordered in Grid Rows and Columns) which can lead to some elements not being seen in design.
Plan your layout properly and think through which Panels would be best for them, having to go back much later and change can be annoying (though admittedly it happens).
Also remember to use partial classes to properly structure your stuff, having to read through 1000+ lines of code to find something can be a nightmare.
In Excel, there is this feature for filtering the cells of a column.
How can I implement excel like FILTER feature in Silverlight Datagrid?
Please advice. Thanks
AJ
Good question - this is a good feature, but not one that can be implemented in 5 minutes.
You don't want to be overriding the rendering of the standard datagrid in any way (too much work), so you need to take a slightly different approach. One way to do that is to draw your own 'header' above the top of the grid - just a grid, with a border and a stackpanel will get you started. Then you need to enumerate the visible columns of the grid, and create a dropdown corresponding to each, and add that dropdown to the stackpanel. Using a simple linq statement you can get a list of the distinct values in each column. When the user selects a value from the dropdown you can then filter the grid's datasource using that value in a LINQ statement.
In reality this is probably going to be at least a week's worth of work to do properly. If you take the cost of that development and the cost of the testing, and measure that against the cost of a good component suite where they already have filtering built in (most of the major vendors do), then unless you are working for a very low hourly rate you will find it is cheaper to buy the components - it is probably safer too, as the components will be well tested and realtively bug free.
Edit (some time later): what i should also mention though is that if you only want to do this on a couple of columns then you could consider using a column header template. If you take this approach though you will also have to do things like copy the various mouse related animations or transitions that might be part of the original colunm header, just so you can keep some consistency across the top of the grid. Personally i would just go with option one and give the user the ability to filter on any of the columns.