Hopefully I am stating that right. I have a WinForm(3.5) app that has 1 Form that is broke into two regions. 1 is the Navigation and the other, a Panel, is the Content. You select what you want in the Navigation Portion, i.e. Demographics, and then it embeds a UserControl containing all the Demographics controls in the Panel.
What I am asking is if each User Control should have a Property for each Control on it. Example: ucDemographics has a textbox, named txtCity. Should there be a Property to store the value of txtCity and allow my Form and other User Controls to access it?
Is that the generally accepted 'Best Practice'?
If not, what is?
It depends on what you want to achieve with your UserControl.
Normally you wouldn't expose the txtCity because the caller could manipulate everything about the textbox then. In most scenarios, you would only expose the current text รก la
public string CityText
{
get { return this.txtCity.Text; }
}
No, that's not really a best practice. The intention of a user control is to compose a new control with its own behavior. You should at most have "several" properties, methods and events that are public and allows a form to interact with the new control. If you find that the only good way to work with it is by exposing its constituent controls that you're better off not using a UserControl but just place the controls on the form directly.
Related
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 am working in windows forms application and have a following issue. I use tabControl in my application and there is a need to change a content inside certain tabPages when users perform specific actions.
for example tabPage one contains a text area and a button, when user clicks button information inside a text area should be stored somehow, and that same tabPage should display new content e.g. more text areas, buttons etc, I assume it is easier to do by using views inside it, so one view can be hidden and another can be shown.
This a to a degree a matter of taste. You can chose to show and hide controls one by one in a method or you can group them in a UserControl which you then show or hide in one command.
I would base my decision one way or the other by these questions:
Are there controls, that will always be visible and how is the layout for these?
How many controls are there to show/hide?
Is there a need to reuse one or more of your views?
The last question may make the big difference: If you want re-use, do go for the UserControl. It is basically meant to do just that: Group controls, like a form does.
For just a few controls doing it in a one by one (in a switchViewMode-method) would suffice, imo.
To add UCs you right-click your project in the project-explorer and chose add - usercontrol. Then chose a nice name, like UC_Goods or UC_Services or whatever your shop policy suggests.
You are then presented with the empty GUI. Now add the controls you need.
Here a decision is to be made: If you will reuse it make sure the controls get generic names! If not it doesn't matter. The reason is, that when you add two instances of the same UC, their controls will have the same names and you will have to qualify them by the parent (the UC)
Here you also script events etc..
Finally add instances to the TabPage as need like this:
public UC_Goods uc_goodsDelivered = new UC_Goods();
public UC_Goods uc_goodsOnHold = new UC_Goods();
public UC_Services uc_ItServices = new UC_Services ();
public Form1()
{
InitializeComponent();
tab.tp_goodsPage.Controls.Add(uc_goodsDelivered);
tab.tp_goodsPage.Controls.Add(uc_goodsOnHold);
goodsOnHold.Hide();
tab.tp_goodsPage.Controls.Add(uc_ItServices);
uc_ItServices .Hide();
// take care of dock style or anchors..
// ..and initialzing fields..
}
This delclares two UC classes and two and one instance of each respectively. Only one is visible. Since one class is used twice its controls have ambigous names until you qualify them e.g. like this: uc_goodsDelivered.Status...
hth
Could someone please tell me the differences between using a Form, Panel or a UserControl.
A form is a control and a container for other controls. A form is the base unit of a windows application.
A panel is a control and a container for other controls.
A usercontrol is a user defined control.
See:
Windows Forms
Windows Forms Controls
Windows Forms Overview
In Windows Forms, a form is a visual
surface on which you display
information to the user. You
ordinarily build Windows Forms
applications by adding controls to
forms and developing responses to user
actions, such as mouse clicks or key
presses. A control is a discrete user
interface (UI) element that displays
data or accepts data input.
When a user does something to your
form or one of its controls, the
action generates an event. Your
application reacts to these events by
using code, and processes the events
when they occur. For more information,
see Creating Event Handlers in Windows
Forms.
According to MSDN the Panel class is "Used to group collections of controls", while the User Control "Provides an empty control that can be used to create other controls".
You are right: this doesn't help you a lot to decide whether you should use a Panel or a User Control.
One of the differences is that a Panel is a ScrollableControl, while a UserControl is a ContainerControl (which is also a ScrollableControl). So if you want ContainerControl functionality, consider to use a UserControl.
You'll probably don't know what a ContainerControl does, so what you can't do with a Panel, hence the following might be more useful:
In object oriented programming, and so also in Winforms, whenever you want a class that behaves like another class, but only slightly different, you consider to derive from the other class.
So if you want a button that changes color when pressed, and returns to its original color when pressed again, (like an on-off button), you might consider to derive from class Button, or maybe from class CheckBox-in-the-shape-of-a-button.
By making it a separate class, you can reuse the code in similar situations. Whenever you will only use it once, then usually we won't bother to make it a special class. We will usually not make a special class for "The Select button in my form, which does ... when clicked", but if you will use this button in ten different forms, then it is probably wiser to create a SelectButton class.
Similar, if you have a group of controls, with some behaviour, and you plan to use that in different forms, consider to create a User Control, where you put this behaviour. The nice thing is that the code of this behaviour is hidden inside the control. Users of your UserControl only have to know what it does, not how this is done. You might even want to hide how this is done, so users (= code, not operators) can't access it
A panel is more or less like a GroupBox without a surrounding rectangle: consider to use it instead of a User Control if you will be using it only inside this Form. Similar to how you would us a "Button that does ... when clicked": because you use it only here, you don't derive from it.
I seldom use a Panel. The derived classes: TabPage, SplitterPanel, ... are more likely to be used only in this form.
Whenever I need combinations of several controls, especially if they interact with each other. For instance, if you have a text box and a label that describes what is in the textbox and an OK button that processes the text in the text box. In that case I usually make it a UserControl.
I could have derived from a Panel and add a Label, TextBox and Button, but then users could mess up with my Panel by adding other items, or calling Panel functions that would mess with my functionality.
Come to think of it: using a class derived from a Panel vs using a UserControl is similar to deriving vs aggregation / composition: If you aggregate, you can limit access to functionality, if you derive, users can access all parent functionality.
So if you only want limited functionality: show / no show, maybe size and position, background, but not much more: consider to create a UserControl. If you want the possibility to change the behaviour, consider to use a Panel, especially if you will use it in only one form.
I need to implement TabControl-like behaviour with manual (on event, on a button click for example) pages switching and having all pages designed and implemented as separate forms. A form to be incorporated (as a panel control) inside main form and replaced by another form as needed.
How to achieve this?
PS: The reason why I don't want to use TabControl instead is because there are going to be too many tabs - I'd prefer to present the list of them as a TreeView and instantiate on demand. The another reason comes from another project of mine - there I am going to implement plug-ins, where a panel inside main window will be provided by a class loaded dynamically and will be runtime-switchable.
I need to implement TabControl-like behaviour with manual (on event, on a button click for example) pages switching and having all pages designed and implemented as separate forms
May I ask why this is a requirement? It seems like the logical approach would be to create a set of UserControls. You can place a UserControl in a form, and you can place a UserControl in a tab. You get modularity without the headache of implementing a very odd requirement which is a use case that the API developers obviously did not think was valid. I just can't think of a good reason to take the route you have suggested.
I did similar thing once, and for that reason, I have ReplaceControl method, which I paste below:
static public void ReplaceControl(Control ToReplace, Form ReplaceWith) {
ReplaceWith.TopLevel=false;
ReplaceWith.FormBorderStyle=FormBorderStyle.None;
ReplaceWith.Show();
ReplaceWith.Anchor=ToReplace.Anchor;
ReplaceWith.Dock=ToReplace.Dock;
ReplaceWith.Font=ToReplace.Font;
ReplaceWith.Size=ToReplace.Size;
ReplaceWith.Location=ToReplace.Location;
ToReplace.Parent.Controls.Add(ReplaceWith);
ToReplace.Visible=false;
}
Only thing left to do is to create some control manually on the form, as the placeholder for your Form. Use label, for example.
You could do this with an MDIForm as the main form, and then plain-old Forms as the separate forms. Or you could encapsulate each element's functionality as a UserControl which you can then swap out on your form in code.
The advantage of encapsulating your UI elements as UserControls is that if, for whatever reason, you need them to become forms in your application, you can just drop the UserControl on a form.
Update: Since you want to use a TreeView to select what the user is looking at, you definitely want to do this as a bunch of UserControls. The layout is simple: TreeView on the left, and whichever control is active on the right.
There's no need to justify not using a TabControl - tabs are the worst UI element in history.
i have developed a gridview control. which as searching, paging ,sorting, as a Functionality. i have made this control as a user control. in the page where i am using the user control. i need to add check box inside the user control[GRIDVIEW].
right now i am assigning the bound fields like this
<uc1:GridUserControl ID="GridUserControl1" runat="server" Header1 ="User " Datafield1 ="User_Name" Header2="First Name" Datafield2 ="First_Name" Header3 ="Last Name" Datafield3 ="Last_Name" />
now is there any way we can add our control's inside the User control [gridview ]
can any one let me know how to achive this
thank you
You can get at a usercontrol's child controls using
myUserControlInstance.FindControl("ChildControlID")
but you probably don't want to. This is rather fragile, due to the lack of compile-time checking. If the control was renamed (or refactored into another control for reuse),this would start failing at runtime.
I recommend either a property on the user control that exposes the checkbox, or enough properties/methods on the user control to set the checkbox's state.
You may also want to consider why the parents need to know about the innards of the usercontrol. I usually treat a control's children as analogous to private/protected methods on a class. Hide the implementation details, so you can change them if required!