Concidering this basic GUI diagram of my application, I am using Caliburn.Micro and try to utilize MVVM as best I can;
I have my mainGUI (black) that is an Conductor, which has a ContentControl
That loads a UserControl when requested from the menu (also ShellViewModel).
This LabelViewModel also contains a ContentControl, which in turn will display a specific label with settings and input w/e.
I want the buttons on LabelView to be able to print whatever specific label (and settings) that is currently presented on the screen
Would someone be able to tell me how get this working using Caliburn.Micro, or the MVVM implementation?
I am thinking of keeping track of the currently displayed ViewModel in the LabelVM ContentControl, by using properties and then use its properties and sent that to a method in my Print class..
Note that I will have multiple preconfigured labels, probably using Enums to identify them
My quesion got closed earlier because it was opinion based; I can't see where I ask for an opinion, since I ask for a way that Button1 on LabelView executes an action with data from Label1View, while using Caliburn.Micro or even better, MVVM implementations.
I am not using anything other than a simple WPF application project in visual studio. I've implemented an mvvm application.
I want to display a list of content changes made by a user. I have a main window view model and it currently just builds a strings with changes. I have objects that I can reuse to display their properties (the content).
Currently, I use a MessageBoxResult to show a really long string with the changes. This is a terrible design (I know), but I couldn't really find an answer to what class a regular wpf project has that would allow me to achieve what I want.
I know there is a popup class I can use. In practice, which is better-- another view model for the dialog, or a popup?
Can anyone provide a simple example of one of the two approaches?
Thank you in advance for your response.
What I've done in the past is have a simple Border control, and inside of a TextBlock and whatever Button controls I need. I bind the TextBlock.Text to a public string property named "MessageBoxMessage" which calls OnPropertyChanged(). I bind the Command of each Button to a separate public ICommand which specifies what action to take in the view model when the button is clicked. I then bind the visibility of the Border control - which contains all of the other controls I mentioned - to a Visibility property.
When I want to show a dialog, I set the MessageBoxMessage to the message I want to show, makes sure the commands are set properly, and then set the Visibility on the Border to Visibility.Visible. This shows the box (border), message, and buttons.
You can even implement a semi-transparent rectangle underneath the border (over the rest of the form) that you set to visible at the same time. This will give you the nice "form dimmed" effect and also block the normal form controls from being clicked. A general note - for this to work, these controls need to be at the very bottom of your XAML as the z-index among controls at the same level is inferred from their placement in the XAML - lower in the code is top level on the form.
Let me know if you have any questions about implementing this if it sounds like what you are looking for.
I've been reading some explanations about the difference between User and Custom Controls, for example this:
http://www.wpftutorial.net/CustomVsUserControl.html
I want to create, for example, a simple composition of a datagrid with 2 comboboxes which are responsible to change the values from the datagrid's items. I want to create a specific control for this because I'm going to use it a lot of times. I would like to implement the logic behind and then in the xaml invocation I only have to specify the itemsSource.
For this example should I create a User or Custom control? Since I will have properties and logic, should I have a viewmodel for this control?
EDIT: Do you know some articles with clear conceptual separation between these 2 options?
Choice is not only between user control and custom control, but among user control, custom control, customizing control template, customizing data template, header template (for collection based controls), attached properties.
Refer to Control Authoring overview
I go by following order of consideration
Attached Properties : If functionality can be achieved, I use attached properties. Example, Numeric text box.
Control Template : When requirement can be fulfilled by customizing the control template, I use this. Example, circular progress bar.
Custom control: If control template cannot do it, I use custom control. Provided I need to customize/extend already present control. Example providing Sorting, Filtering based on header row in GridView (GridView is present in metro apps, used just to illustrate the example)
User control: Least preferred one. Only when composition is required, and I am unable to do it using custom control. Like in your example, 2 Combobox, and 1 datagrid. User controls does not provide seamless lookless feature that can be leveraged through custom control or control template.
You already have some great answers that explain the differences but also understand that custom controls and UserControls have different purposes:
A UserControl typically encapusulates some sort of composite behaviour. If you have an application that needs to edit contact details in many places, for example, you could create a custom control that has the labels and text fields for all the data laid out with a submit button that has the relevant code and reuse this control throughout your application.
A custom control is a control that is derived from one of the WPF control classes (E.G. Control, ContentControl etc.) and has to be created in code.
These control usually have a single cohesive purpose (think TextBox, ComboBox, Label) rather than acting together as a whole (although this doesn't have to be the case).
UserControl's are usually easier for people unfamiliar with WPF as they can be visually designed.
My suggestion would be to start off with a UserControl. You can always refactor this into a custom control at a later date as you become more familiar with the way WPF works. Creating your control as a custom control will require knowledge of ControlTemplates and Styles as you will need to provide your own to define a look and feel for your control.
When all is said and done, as long as the control behaves correctly, it doesn't matter which approach you use.
See this post for an example of two approaches to the same problem. The post author wanted a control which can present modal content in front of the primary content. The post author actually answered his own question by implementing it as a UserControl. I have added an answer to the post which creates the control as a custom control but both have the same end effect.
If you have a view-model and you wish to create a view for it use the User-Control.
If you need an autonomous control that has no specific view-model,
you probably need a custom-control.
If you find that the functionality you need as whole, already exist in other controls you need to override an existing control template.
(i.e: for a diamond shaped button - you need to override the button control template.)
Regarding attached-properties and attached-behaviors, those are useful when you have a control which you want to extend with more properties or you want it to behave slightly different than its default behavior.
In the provided case of the composition the OP described, it can be achieved with either user control or custom control. I would prefer a custom control since there is no specific view model provided, the "input" is only a property bound to an item collection.
Oh, and, I am sorry for slightly being late.
The best explanation is in the msdn. CustomControl is more a "virtual" name, there is no class called "CustomControl" in WPF, instead its meant creating a new class building on top of one of WPF control classes, like Control, ItemsControl and even more specific Controls like TextBox or Button.
For your specific case, a UserControl should be enough, creating a CustomControl is something that can easily be avoided. While its not a bad thing, a lot of people, especially beginners in WPF coming from WinForms tend to subclass more then necessary.
If this is somehow your first time building controls, I recommend UserControl as VS lets you design its interface more easily. Custom Controls are more powerful, but you have to CLEARLY separate your control's logic from its interface and this requires a bit more preparation.
You can easily Visually design CustomControl.
Create new UserControl (or Window). Create its xaml structure visually in Designer. Copy-paste body of the resulting xaml inside ControlTemplate of your new CustomControl (Eg. in generic theme file).
If I remember right, you are also able to visually design CustomControl template directly, in Blend.
Of course you can also instance the wip CustomControl in a Window and put the Window's Designer view as new panel above the control's xaml view in VisualStudio.
Some xaml bindings from style template don't show in Designer like this though, until I rebuild.
[ Imho GUI is mainly a visual matter and should not, and doesn't need to, be created in code. ]
Well to create a Custom control you need to implement it as a User control. Your own User control is called a Custom control. It is pretty simple.
UserControl is the base class for containing your custom content :
<UserControl>
Your custom WPF content
</UserControl>
I don't totally agree with the article. However in your case you need a UserControl that you can re-use latter in your UI.
I'm developing a WPF application in C# and was thinking about implementing a custom UI element accross various windows.
I would like to have a minimized tray (only about 4px visible) that expands after clicking on an icon next to the tray. The expanded version would show all controls and would minimize when I click the icon again. I created a quick HTML concept to clarify things.
I know I could put a stackpanel and button in my application and making both of them move up when I click the button, but then I would need to duplicate the code a lot.
Though I'm experienced with C#, I'm fairly new to WPF interface development/templates, but I'm sure there has to be a way so I can use that UI element accross my application without needing to copy/paste a lot of lines of code in my form class file.
I hope someone can help me, or at least point me in the right direction.
There are three ways to customize your elements.
1 If you only need visual modifications you can use styles to change the appearance of the .net default controls. You can even override / extend the default templates.
2 If you want custom logic in a control you can create a custom control. The framework brings a lot of "primitives" to build upon. Examples are ContentControl or HeaderedContentControl. Say you want to build a custom expander control you can inherit your custom control from HeaderedContentControl which provides you with Header and Content properties and you just have to implement the toggling logic yourself.
CustomControls are a good choice if you want to build basic functionality which can be used throughout your application. They can be themed/styled depending on the use case, too (see 1).
3 If you want to compose different controls into one control you can create a UserControl. User controls are composed using XAML. Most top level controls are user controls driven by a view model.
Your case can be build using a Popup and ToggleButton or an Expander.
The decision depends on the desired behavior. If you want the opened panel to move following content down you need a expander. If you want a dropdown like functionality you need popup.
If you use a popup just bind the IsPopupOpen Property to IsChecked of the ToggleButton and set PopupStaysOpen = false to wire the button to your popup.
If you use an expander control you should create a style which can be applied to all equal expanders in your application to minimize the required XAML in each view.
How about using Expander Control?
There's a control called an Expander that is perfect for this. You'll have to style it to look like you want, however it has the functionality you want built-in.
A better explanation, I hope:
I have a toolbar with 3 buttons on it, all three bound to a Command (including a CommandParameter)
this toolbar is used on several screens
the xaml of the toolbar is exactly the same over all those screens
I want to remove the toolbar instance and replace it with a user control that provides 3 commands, so I can keep the bindings in each screen. The plan is to later change the toolbar functionality, but the external programming interface (namely, 3 commands) is the same.
So:
I created a user control, and created 3 sets of dependency properties for each command (OneCommand, OneCommandParameter, OneCommandTarget) so I can use these for the binding.
I moved the toolbar xaml inside the user control xaml.
I modified the bindings on the toolbar buttons to bind to the intristic user control properties
on each screen (or really, only the first for now) I replaced the original toolbar with the user control,binding the new properties to the correct commands.
The control shows, but the buttons don't work.
That's about it.
--
Original explanation - not so clear:
I have a WPF user control encapsulating a number of buttons. Previously, the control was a Toolbar with a number of buttons on it, but since I need exact the same functionality on a number of screens, I refactored the toolbar into a custom control.
However, I'd like to keep the command bindings of the original buttons.
I created 3 sets of dependency properties (XCommand, XCommandParameter and XCommandTarget) on the usercontrol.
In the user control xaml I bind the "real" buttons to those properties (each button to each set of properties).
Where I use the usercontrol, I bind the new properties to the real command bindings.
In essence, I want to keep the ICommandSource functionality for each "command" that the user control exposes. However, this dual databinding scenario doesn't seem to work, or I'm doing something wrong. :)
Is there a better way to do this? All I need is to "bridge" the commands from outside the control to the inner buttons so the Execute and CanExecute functionality remains.
I solved this. There was a bug in my RelativeSource in the internal control bindings. It works fine as expected, now.