Winforms question:
Better design to have 1 control, say a dropDownList, conditionally bind to multiple datasources or multiple dropDownLists with each their own datasource?
You'd use if then logic to select which datasource to connect to with the first option. You'd use if then logic to select which databound control to enable and show() with the second option.
I'd go with the first one, unless the dropdowns controls themselves were different. It might not be just databinding that changed, colours, styles, event handlers...
You could deal with them as well of course, but at waht point does it beome too messy.
There is one thing though, if you do all the controls, position them in code when you make them visible, don't lay them one on top of the other in the designer so you don't have to, terrible habit that.
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 need to show a similar-looking dialog in two different places in my application, one place as a modal dialog box and one place embedded into another menu.
From my limited understanding of WPF, it looks like Styles would allow me to write a single UserControl and customize its colors and fonts for both scenarios. However the changes are a bit more extensive, some of the element positions (for example, TextBox) are in different relative positions.
I am not sure if this can be done with Styles, or if there is a more appropriate way to do this in WPF. Worst case, I can write two completely different UserControls, but that is very bad in terms of maintainability so I'd like to avoid it.
Sure you can do it with styles/templates. Just give each of the styles a key and use the key to access the right style at the right place:
<YourUserControl Style="{StaticResource firstStyle}"/>
If you use a pattern like MVVM (I prefer MVVM Light) this is quite simple to do. You would write one ViewModel that captured all the data and behavior you wanted to expose and then create two views the way you want them, both using the same view model.
This scenario is one of the core intents behind the MVVM pattern. You're right that it is "bad" to write the behavior/plumbing twice, but the views are different, so you're not violating any re-use there.
I need a ListBox which will contain several options. I need checkboxes exactly(style), not radio buttons. Is there any way i can allow only 1 checked checkbox at the moment? I'm using MVVM, so i can't just check or uncheck them manually, it's against the rules.
And if i can't make such functionality - is there easy way to style radiobuttons to look like checkboxes?
Aside from a flawed requirement*, the only way to do this is to uncheck all checkboxes, then check the particular indexed checkbox.
Or alternately (cos it does the same thing, but sounds longer), iterate through all the indicated checkboxes and find whichever one is set to true that is not the one you want checked, then set it to false.
flawed requirement: A series of checkboxes indicates to any user that they are allowed to select zero or more items. A series of radiobuttons indicates that they are allowed to select only one. This is something that has been drilled into users since before Windows 3, and that all non-IT will not question. You'll break their mental model, which is worse than looking pretty. Please have management revise this requirement.
HTTH. YMMV.
If you are using MVVM and what to stick to the "rules" then your ViewModel should have a property to which the checkboxes bind. Its the up to code in the ViewModel to ensure that state of this property is correct.
So code in the ViewModel where one property gets set to true may need hunt through a collection to find similar items whose matching property needs to be forced to false. The View then simply reflects the current state of the ViewModel.
Well, in the end, i used this solution
Scenario: I have a (numeric) textbox, a button, and a label. When the button is clicked I'd like the label to "animate" to the numeric value in the textbox (like a spinning dial)
Given:
a) that animations in storyboards cannot have databindings (because they are not FrameworkElements)
b) the lack of triggers in Silverlight
What is the best, and with least coupling of the view model to the view's storyboard, way to update the target animation value and start the animation when the button is clicked?
Note: The scenario is conceptual, so don't concentrate on the specifics of 'animating' numbers or anything
If your goal is strictly to reduce the code-behind in the view I think that an attached behaviour on the Label would work for this. The attached behaviour on the label would expose the number to be animated to and when this number changes an animation (in code) would be run to animate from the old value to the new value.
One drawback is that your animation is now in code, unless you store a templated (just has fake values to start with) version of it in a resource file somewhere where you can load it as needed and replace the templated values.
This article from Josh Smith seems to be the authority on Attached Behaviours;
http://joshsmithonwpf.wordpress.com/2008/08/30/introduction-to-attached-behaviors/
I recently had to solve a similar problem in an MVVM application. My problem was that I needed to animate a container's height from zero to auto. Since Auto is a dynamic value I recognized that the animation (or storyboard) would need to be built (or manipulated) on demand. The solution that I put in place involved using view code-behind to update and fire the animation.
This isn't the most MVVM-friendly approach; however, animations in WPF can be tricky in XAML. Since this solution is really just a workaround for a XAML limitation it seems okay to tie the code directly to the view. Likewise, if the views were mocked then there would be no framework elements to animate, so it really wouldn't make sense to place this code on the VM side.
Does anybody have a better approach?
I'm using PRISM (and thus the MVVM pattern). I've got a complex DateTime picker view with radio buttons.
The user can pick today, yesterday, a date, a week of a year, etc. I use radio buttons for the different choices.
What's the best way to do that in MVVM?
I really can't think of a clean way. I could create lots of custom behaviors to add to each item to track them but it doesn't seem maintainable.
I'm going to put some code-behind but I really don;t like that and to me it breaks the MVVM principle (put everything in the XAML).
Does anyone have a better idea on how to go about that?
Keep the RadioButtons, add an enum type to your VM that can return things like "Today" "Yesterday" or "Tomorrow." On the UI side create a ValueConverter that takes a parameter like "Tomorrow" and compares it with the bound value on VM, then returns the bool? needed by IsChecked.
Put it in code behind.
The M-V-VM pattern is not "put everything in xaml" it's "separate concerns". Your VM wants a DateTime right? In which case it doesn't care how that DateTime is being chosen it just needs a DateTime.
Putting View logic in the ViewModel isn't a good idea as you're now giving the VM knowledge about the workings of the View. The flow is meant to be View knows about the ViewModel which knows about the Model. The reverse is not normally true. (As with all things computer related there is always exceptions)
Hope this helps.
How about a ComboBox instead of the RadioButtons presenting a list of TimeOffset (custom class) bound to your ViewModel, with a corresponding SelectedTimeOffest property.
If you need to display extra information depending on the type of TimeOffset, e.g. a WeekOffset (subclass of TimeOfset) with a WeekCount property, have a content control with several DataTemplates customized by the type of TimeOFfset.
Just an idea...
you could create a enum, bind the values of the enum to a listbox, retemplate the ListboxItems
this post is using silverlight, but something similar should work
http://leeontech.wordpress.com/2009/03/18/creating-radiobuttonlist/
The ViewModel is designed to present the model in a way the view can consume.
In this case, you could have a boolean property for each button in the VM, and when a button updates it just sets all the other properties to false. Then in your View you can bind each properties IsChecked to the corresponding property in the ViewModel.
Also, be aware there is currently a bug in binding radio buttons in WPF. Here's a potential solution.