I am trying to define a common base page for all of my Windows Phone 7 pages that includes a common place for derived pages to add their markup, similar to content placeholders in ASP.NET.
So far the code samples I have seen all add code behavior, but none show how I can use a base page to do the following:
place the application title in the top left corner
place the company logo in the top right corner
have a dynamic (meaning the user can change it) background image
I can define a custom MyTitleControl to achieve most of the items above, but I would still have to rely on all the page referencing it (rather than deriving from a common base page). Is this even possible in WP7?
The only way to do that with a base page class is to use "loaded" event or better method OnNavigatedTo and change visual tree as needed.
PhoneApplicationPage Class derives from UserControl, so it's visual tree is built using InitializeComponent auto-generated method.
It's generated to read XAML and instantiate controls and set root control as a Content of current user control (in this scenario Page).
So you might use it later (not in ctor) or modify tree after this method.
Another option might be creating Style for page and just applying it to all pages.
You can't. This is a limitation of WP7.
Every WP7 app has a single instance of PhoneApplicationFrame associated with it. Everytime the current page changes, the PhoneApplicationFrame 'Content' property is set to the PhoneApplicationPage. And a PhoneApplicationPage does not support additional PhoneApplicationPages inside.
The only way to accomplish something similar, is to convert all of your pages to UserControls, and ensure there is only one PhoneApplicationPage .
You can inherit from PhoneApplicationPage and give your new class additional properties, a new default Style, a new Template - after all a page is nothing but a UserControl with custom properties.
Then alter your myPage.xaml.cs and myPage.xaml files to inherit from your new class instead of from PhoneApplicationPage.
Related
I have a UserControl with a custom property:
public Size TestSize { get; set; }
I would like this property to show up in the properties window during design time of the UserControl, and not only where the UserControl is used as an instance (e.g. when dragged/dropped on a form).
Example:
In the designer of the UserControl one can set properties like "AllowDrop", "AutoScroll", "BackColor" etc. I would like my custom property to show up just the same way in the designer.
I have considered and tried adding attributes to the property like:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
but that does not seem to be the way to go.
Any help is appreciated!
If you really want to show the property in the designer of UserControl1, then the property should belong to its base class. That's because of how designer works
Assuming the root element of the designer is UserControl1, then the properties that you see in properties window, are browsable properties of UserControl1's base class (which is probably a UserControl). To learn more about it, read the second section of the answer.
In most cases you don't need to show those properties in designer, unless you want to derive multiple controls from that base and configure that property in design-time of the derived control, but I assume you know your requirement and now you are able to make a decision base on your requiremets.
This is the way that designer works:
It deserialize the .cs file (and looks for InitializeComponent method, or designer.cs file, also considers the designer-related attributes).
It creates an instance of the base class and add it to the design surface, and applies the deserialized property values. (So the instance that you see in designer, is an instance of the base class. It's a trick. For example, that's why if you have an abstract base class, you cannot have the derived class as root designer without some workarounds.)
It creates the whole control/component trees based on the deserialized code. (So the controls which are on design surface are real instances of the controls)
Of course there are a lot of other things happening, like making the extender providers working, or pre-filtering or post-filtering properties in design-time, but in general it works like what I explained above.
More information / Related Posts
Some other related answers:
A similar question/answer for Form: Custom browsable property for Form at design time
An answer explaining how designer works, also contains an interesting example shows how .cs file which is full of syntax errors can be shown in designer: How does Windows Forms Designer work?
I'm not very clear of when to use a CustomControl and when to use an UserControl. I basically know what CustomControl allow(more customization when using with template).
I want to make a "File browse" control in WPF(TextBlock that displays the current path + Button that trigger a "Open File Dialog").
I'm not sure, because at some places I find that they say this should always "replace" a WPF control. I was more thinking that a a CustomControl was more like a way to display and edit one new semantic value (in my case, a "File(path)").
So, if we don't take into account which one is easier to do, what would be the more adequate between CustomControl and UserControl for the "FileBrowse" control that I'm speaking about?
Thank you
Custom Control:
A loosely coupled control w.r.t code and UI
Derives from Control
Defines UI in a ResourceDictionary
UI can be changed in different projects
Has full toolbox support
Defines a single control
More flexible
User Control :
A tightly coupled control w.r.t code and UI
Derives from UserControl
Defines UI as normal XAML
UI is fixed and can't have different looks in different project
Can't be added to the toolbox
Defines a set of controls
Not very flexible like a Custom Control
When we talk about differences, it is more important to emphasis on the context when to use what:
When you have a rapid and fixed content in your UI, use UserControl.
When you want to separate some basic functionality of your main view to some smaller pieces with reusability, use UserControl.
When you want to use your control in different projects and each project may want to change the look, use CustomControl.
When you want to implement some additional functionality for a control, create a CustomControl derived from the base control.
When you want to apply themes to your controls, use CustomControl.
When you want to add toolbox support for your control, so that your user will be able to do drag and drop to the designer, use CustomControl.
I think a UserControl is the one to choose, for it is used for a kind of "assembly of existing controls". In your case a button and a file open dialog. It will then get a specific look and feel (for example the default look of a button and the default look of a file open dialog).
The CustomControl is kind of the other way round. It has no look and feel by itself. It is completely abstract concerning layout. The layout comes into play, wwhen assigning a style to it.
In general a custom control extends an existing control while a user control creates a new control type from a collection of existing controls. I would say that a user control is better suited, based on the information you've given.
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 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 am developing controls for WP7 application. I am aware that I can quickly create control by inheriting from UserControl class (that derives from Control class). Also, that such controls cannot be customized, i.e., all the properties associated with control are those harcoded in user control - they cannot overridden in xaml etc. But can somebody please share the best practises / situations as to when to inherit directly from Control class vs ContentControl/ItemControl class vs UserControl class (am I missing any other options?)?
Thanks.
Here is a brief description of each control types that you mentioned:
1.ItemsControl - it is usually used when you want to have a control with items like for example ListBox,TreeView etc. One of the most important parts when deriving from ItemsControl is to override :
GetContainerForItemOverride
IsItemItsOwnContainerOverride
PrepareContainerForItemOverride
Here is an example:
http://www.silverlightshow.net/items/How-to-inherit-from-ItemsControl-and-create-a-UniformGrid-with-containers.aspx
Note that the sample is not with the latest Silverlight version but it explains in details how to implement a custom control.
2.Control - when you want to implement a simple control that has no Content or Items properties like a TextBox for example you can derive from Control.
3.ContentControl - when you need to place some content in the control.Like for example the button Content. It depends on your need what will be the choice of the base class.
You can also take a look at the rest of the tutorials that SilverlightShow provides connected with "how to implement a custom control".
I hope that this will answer your question.