I know how to create a simple XAML interface for a page, but I spend a lot of my time copying and pasting code since I have no idea how to create reusable XAML in a proper way, I know about styles but they don't quite fill the role. What I would prefer to do is to call them in the following way:
<CustomElement attribute1="bla" attribute2="{Binding somethingElse}"/>
Just like all the other GUI objects in the Silverlight framework.
Any help or hint would be useful.
Basically there are two options. Both solutions act like any other Silverlight control. They can be inserted at random places in pages like you would normally insert a Button or a StackPanel. The option of choice depends on the specific reuse scenario.
Create a UserControl. These define their own XAML layout and are very easy to create. Consider looking at ScottGu's tutorial.
Create a custom control. Custom controls also define their own XAML layout but through templating and styling. They are harder to create but support templating; this means other developers can decide that they will use the code behind your control, but specify a completely different layout. For more information look at Silverlight templating.
For a (much) better understanding, please look at this page comparing the features of UserControls and custom controls more in-depth.
Related
In my UWP app, my control options are User Control and Templated Control. My understanding of a User Control is KIND OF clear at this point.
I was told that a Custom Control's style/template is only instantiated in memory once, and that this only happens at the time the control is first used. That's what I want since I know the control I am creating will be used in a ListView.
In the book, XAML Unleashed, however, the author creates his Custom Control by starting with a User Control, and then simply changing it's base class. The thing is that the control he created calls InitializeComponent(). I hear that this type of class uses more memory because it is re-instatiated for each item in the ListView.
Also, I never thought that Custom Controls used the InitializeComponent() method. I thought there was simply a call to this.DefaultStyleKey = typeof(MyClass); in the constructor. What gives? I am confused on what is what...
And last, why is the style/template of the Templated Control placed in the global Generic.xaml file, instead of its own separate file (i.e., xaml file and a code-behind file pair)? If the control is supposed to be custom and "portable", then shouldn't it be totally separate from other code? I haven't found a single article explains any of these things in detail on any level.
This is something most people get wrong so I'll try to clarify a few things for you.
Memory
The whole memory thing, it's all in the Visual Tree. When you instantiate any control, whether templated or UserControl, you will use up memory with every instance because in both cases you are creating a full copy of the visual components in the template.
The templated control will create a copy from the ControlTemplate while the UserControl parses the XAML file when InitializeComponent() is called.
Memory usage will be the same if you create 100 templated controls or 100 user controls if their content is the same.
Usage
Templated controls are best for situations where you're creating a single component, like a Button, Slider, MyStarRatingInput, etc. and you're giving the users of your control the ability to swap out the template with their own. It takes a lot more effort to do this properly than UserControls because the logic has to be template agnostic and your templates have to react properly with visual state changes.
A UserControl is best for layout or views, like forms, popups, screens, pages, etc. You will not give someone the freedom to tamper with the content of your view. You may expose a few public/dependency properties if some views are reusable in a small way, but generally they are set in stone.
Generic.xaml
I honestly don't have an answer for this. Microsoft should've allowed multiple resource dictionaries to enable cleaner partitioning of control templates. Generic.xaml is a reserved filename that referencing projects will look for as the root source of the base styles of your controls. You could reference other XAML files from Generic.xaml, but that's annoying and it bloats the root of your resource dictionary. For now, you're stuck with this method.
Recommendation
If you're sharing a control library, you would want to use templated controls as much as possible. If you're building controls, views, pages, etc for your current project and they're not meant for reuse, then use UserControls.
You can still create a UserControl in your control library if you plan on owning the template and forcing all users to accept your design.
I also recommend templated controls for items that you plan on instantiating a hundred times in a single view, like a ListView. You will see noticeable speed improvement if your template is preloaded into memory instead of parsing a XAML file on every instance.
I was trying to do something in visual studio the other day when I realized, if I could just make a form control to do it for me it would be allot easier, except I have no idea how to do that, I want the form control to have grids, each square having its own color property, if anyone knows how to make form controls, or even better knows how to make something like what I just described, I would be very happy :D
This MSDN article is a basic step by step outline of how you can write a customer control.
Unfortunatly MS has not figured out how to do avoid link rot -- so you may need to search creating custom winform controls to find this if you come in the future.
You are usually best servered by subclassing an existing control and customizing it.
You might also find some of the freely available winform control projects a gold-mine of useful info if you get serious about this.
However, it sounds likely what you should consider doing is creating a "User Control", this is usually simpler for a composite of few existing controls. This
article on the types of controls for winforms may be a useful overview for you.
Beyond that you really should use S/O if you are trying to resolve a specific problem you are having when you are coding. Google is a more appropriate tool for finding tutorials, etc.
1) Inside your project: Solution Explorer --> Right Click the .csproj --> Add UserControl
2) Drag and drop gridBox or any control you want into your custom control.
3) Check the ToolBox, your custom control should be located at the very first selection
I have recently reviewing someone's code and come across a User Control whose UI is like this screenshot
This control has no code in its code behind file, i am thinking we could move all the xaml code of this user control to a control template and use it whereever required. I want to know if this a good practice and should i do so?
Is their any performance and design benefit of one approach over another?
I want to know if this a good practice
So first we should define good practice? I will give the agile good practice point of view: do it only if you need it. Thus for you the answer is in your question:
use it whereever required
Is it required in any other place? If so, use a Control Template. If not, use a User Control, which will be more readable for the next developper anyway (Keep It Stupid and Simple).
Since ultimately this is going to be a UserCotrol,Now suppose some other team working on other module require this control and they want Loaded event of the Datagrid within this Control, Now if you create it as datagrid within usercontrol then they can easily access that datagrid and subscribe Load Event to it. If you will do it in ControlTemplate then it will be difficult if not impossible.
I have got my Mainwindow class , Mainwindow.xaml and Mainwindow.cs. Problem is I have got 4 tabs and each tab has own functions. All this is on my Mainwindow.xaml and cs. Is there any way of separating them because my Mainwindow.Xaml is getting bigger and bigger and then I get confuse with so much code.Probably is bit basic what I am asking but I dont know how to do separate with xaml, becasue I want to keep the layout as it is.
Hope I have explained well.
Thanks in advance
You can use different UserControls for each tab. And each tab has the corresponding UserControl like this:
<myControls:userProfileTabControl />
Here is some more documentation on how to create and use a UserControl in WPF. There is also a video over att WindowsClient that talks about "How to Create a User Control in WPF".
When you feel comfortable with the basis of WPF you might want to consider looking into the MVVM pattern, you can read about it over at MSDN, there are frameworks to use to make MVVM easier such as PRISM. But often they tend to do things a bit more complicated.
Start off by seperating your tabs into different User Controls and go from there.
If it's a small application, you can create a User control for each tab's content, and then implement all the logic there. You then embed your user controls in each tab.
If the application can grow, or you want to put a bit more of order in there, take a look to The PRISM Framework
Im looking to create a custom ASP.NET container control that will allow me to drag further controls into it within the VS designer.
The final HTML that im looking for is very simple..
<div id="panel1">
<div id="panel2">
</div>
<div id="panel2">
</div>
</div>
With additional controls being able to be dragged into panels 2 and 3.
Im sure its very simple but im struggling to find examples that will help.
Any pointers or ideas are appreciated!
Cheers
Stuart
I've done such things in the past, and yes, from my experience at that time there is not much documentation available. Even worse, at that time some of the documentation was incorrect or vague!
So, to save you all the headaches (ouch, it already starts to hurt when I just think of it :-P), here is some information you definitely need to know.
Basically all controls are for run-time use only. You can attach a ControlDesigner to a control with an attribute on the class definition, which the design time environment (VS.NET IDE) will load and use as a layer on top of your control.
Templates
Chris' suggestion to use Templates is in the right direction. Your control needs to store somewhere the 'content' of the div's, and Templates are the perfect solution. Make sure you get this part right at first. Note: template properties can behave weird if they have a set clause! Moreover, check the use of NotifyParentAttribute also.
When you've got the templates in place, and you can use declarative syntax in ASPX pages to add controls, and they render well, then you can start working on the designer.
For the designer you have 2 options; the easy and complex way.
Easy designer solution
Let's start with the easy way. The base ControlDesigner classes already provide a framework to show templates. You have probably already seen this in action, like in the GridView control and its template fields.
Check out the following MSDN article on creating a template control designer.
With this easy solution, you get an automatic implementation of the smart tag (the arrow to the right of a control during design-time), and can select a template to edit from a drop down list.
Complex designer solution
Now, if this is not really satisfying for you, and you would like to be able to edit controls just like a Panel control, then you have to dig deeper. So here is the complex solution using Control Designer Regions.
See the example in the example in the EditableDesignerRegion class.
What this example does, is overriding the CreateChildControls of the designer class. Remember I said the designer control is a layer on top of your run-time control? So this CreateChildControls method will run after your control's implementation. What you have to do, is mark a HTML element within your render output with a special designer region HTML attribute. In this way, the designer knows what part in your rendered control should be a region.
Now you have to instruct the IDE to assign a editor or viewer to your regions. You have to do this in the GetDesignTimeHtml(DesignerRegionCollection regions) method (notice the overloaded version of this method). As you can see, this method receives a collection of regions. You have to assign your editable of view regions to this collection. Important here - and this is the badly documented part - is that the order in this collection is very important. The value of the region attribute in your HTML, refers to the index in this collection.
So, now we have defined regions in our rendered output, assigned a editor or viewer to it. Next up is how to fill these regions and store the value from these regions back into our controls declaration.
These two actions are handled in GetEditableDesignerRegionContent and SetEditableDesignerRegionContent methods of the control designer. Here you see why it's important to name the regions that you've added to the collection in the GetDesignTimeHtml method. In these two methods you receive the region reference and by it's Name property you could determine which Template property of your control to read/write.
To read and write the template properties we use the magic of the ControlPersister and ControlParser. The persister creates an template instance from declarative ASP.NET (HTML) code. The parser does the job the other way around; creates plain HTML from a template instance.
In a nutshell
So it's up to you to decide whether the standard template editing framework is good enough for you. If you want to have fancy edit capabilities for both of your edit regions in your IDE, then you will have to implement the complex solution. Otherwise just stick with the simple implementation. The examples mentioned will help you a lot.
Here is a link to a MSDN article regarding what you are trying to do, unfortunently there is no VS designer support so it renders correctly from the server but not in the IDE.
How to: Create Templated ASP.NET User Controls
http://msdn.microsoft.com/en-us/library/36574bf6.aspx