I am automating a WPF application using Coded UI.
So, while creating a object of a control say WpfText i need to say:
WpfText tag = new WpfText(parent);
Here i need to pass the parent control to the constructor, So is there a way to find the parent control of a particular control in wpf application?
I can record it using Coded UI test builder and then see the generated code but is that the only way ? bcz i find it too cumbersome to do this way.
Within a Coded UI test the TopParent property of the UITestControl class, see here for more details, can be used. To move up through the ancestors of a control towards the top parent the GetParent method of the same class, see here, can be used. There are several other methods in the class for other ways navigating through the control hierarchy.
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 writing a custom control whereby it requires a specific parent for it to work.
In this case, its the Canvas panel. however where do i put the code to check that when it adds to the logical/visual tree, it throws a NotSupportedException?
Override the OnApplyTemplate method in your custom control.
If you need a specific parent to work, I would advice creating a custom items control with a specific item container control and a specific items panel instead of forcing this behavior through an exception.
I have sets of controls contained in individual GroupBox controls.
So say GroupBoxCommon contains Common UI Items, GroupBoxSpecific contains Specific UI items, etc.
I have a way of stacking them in a single UI (floating panel) based on the current selection in the app.
I am just wondering how I should store these sets of controls? Should I create separate forms for each inside this single assembly (that's used by the app).
Should I create them dynamically, as in:
Create GroupBoxCommon
Add Button
Add Button
...
Or should I have them in a single form but offsetted?
To me #1 seems to be the way, but there might be a better way to do this?
In the all I will do is to fetch these sets of controls and stack them in a single UI.
Put each group of controls inside a UserControl. That's what they are designed for, and it will probably make your form code simpler because it will be dealing with less controls.
There is no problem defining UserControls inside a DLL, there's even a project template for it ("Windows Forms Control Library" IIRC).
I tried to create a custom user control in C# that handles other controls that are added to it. The custom control consists of two panels. What I'm trying to achieve is, that if another control is dragged to my user control in design mode (or added programmatically at runtime) I want that control to be placed on one of the panels.
I tried to handle the OnControlAdded event but that didn't do the trick...
Markus wrote : "if another control is dragged to my user control in design mode (or added programmatically at runtime) I want that control to be placed on one of the panels."
I am going to interpret the above as meaning you want the Design-Time dragged control to become a child control of one of the two internal Panels of your UserControl : if that intrepretation is wrong : please disregard what follows :)
Also, just to avoid confusion : you are absolutely correct when you observe that Panels, or other "container" Controls, in an instance of a UserControl placed on a Form at Design-Time, do not "consume" or "swallow" dragged over controls as you might expect : in fact you can't even select them individually : they are added to the UserControl's ControlCollection.
Fortunately for you, in the design-time drag-drop case there is a good solid code example you can study and use on CodeProject by Henry Minute : Designing Nested Controls : that article will show you how to inherit from ParentControlDesigner so that child controls which are containers of a UserControl at design-time can function as containers in the way you are looking for.
In the case of your wanting the consumer of your control at run-time (programmer) ... assuming they don't have source, so they interact with your UserControl as a "black box," able to "see" only Properties, and Methods, available Events, etc., you've made Public ... to control where an added Control is placed : you have a decision to make about how you wish the consumer to access the Panels. You could expose them "directly" as objects, via Public Properties of the UserControl, or you could expose only a Public method for adding controls for each panel.
Why not just drag it into the panel, or give one of the panels a public accessor and do all your programmatic adding to that panel directly?