To realize my application I have used a lot Blend3. When Blend3 wants to link a resource to another resource, it uses many times the link-type "DynamicResource". As I have understood (but I could have understood not well), the "Dynamic" links have sense only if I want to modify the links at runtime. In other cases they use more memory in vain. I don't want to modify anything at runtime, then the question is: have sense to replace "DynamicResource" with "StaticResource" in all my application?
Thank you!
Pileggi
Blend works better in design time with DynamicResource. See:
http://blogs.msdn.com/b/unnir/archive/2009/03/31/blend-wpf-and-resource-references.aspx
The money quote from that:
a) Should I use Static or Dynamic
resource lookup?
Blend def. plays
better with dynamic resource lookups.
You could use a static resource lookup
as long as the resource was not
located or merged into App.xaml.
People have raised concerns around
performance issues with dynamic
resource lookups (you pay for what you
get). While that might be true, an
interesting data point is that the
Expression Blend source code uses a
ton uses dynamic resource lookups for
our own UI (of course, we too use
static resource lookups in places
where the resource would never change,
or where it not possible to use a
dynamic resource extension, for
example non-DPs).
Related
Before I begin here is a reference to how I implemented a template selector with Silverlight.
http://geekswithblogs.net/tkokke/archive/2009/09/28/datatemplateselector-in-silverlight.aspx
Everything works great. But the solution just doesn't work in blends making things more difficult to visualize overall. Is the correct work flow to just create a UserControl from the contents and embed it inside the Resource Dictionary to make it blendable, or is there a better way to do this?
Either way, I'm asking this question and posting the Template Selector solution at the same time, because I found it useful. Better solutions are very much welcome.
fyi.. sl4,.net4, latest blends.. all the new toys.. using mvvm light(little relevance).
I would recommend you go with the the following kind of implementation: DataTemplateSelector on CodeProject.
The drawback of the link you posted is that the location and name of the templates are hard-coded in the ContentControl's implementation. With the approach provided in the article I link to, the data templates are accessed in-line, or by regular {StaticResource} references (which means more flexibility), and on top of that, Blend knows what to do with that.
If you need to access a WPF control from the code behind, you need to supply a Name attribute to it in XAML.
In many cases, you don't need to access controls from the code behind, since a lot of coding logic such as binding is better applied directly inside XAML.
My question is: Is there a performance gain from not supplying the name attribute to controls? Or is it a good habit to give names to all controls on the page?
Yes there is definitely a performance gain from not supplying "name" attributes.
WPF's "Name" mechanism can be useful, but it uses extra RAM and CPU in several ways:
The XAML compiler allocates an extra slot in your class for every named object (4 bytes each)
The XAML compiler adds code to your class to initate each of these
The BAML processor calls back your code to initialize the name in each case
The BAML processor also adds the name to a dictionary, requiring an additional 20+ bytes per name
When looking up names you really need you may run into dictionary collisions with names you don't really need
For a simple control, adding a Name to control can increase the cost of using that control by 5% or so. That's not a lot, but why waste your CPU cycles and your RAM on names that are unnecessary?
Bottom line: If you don't need Names on your objects, don't name them. Usually the content or binding of a control is plenty to identify a control's purpose. And if that isn't enough documentation, you can always use XML comments, which are free.
I'd have to say it is a very bad habit to name all your controls, not just because of the cost but also because it encourages you to refer to your controls by name rather than using proper view model and binding techniques. Most of my XAML doesn't use "Name" for any controls, let alone all of them.
Although Hungarian notation is considered bad practice nowadays, it is still quite common to encode the type in the name of user interface elements, either by using a prefix (lblTitle, txtFirstName, ...) or a suffix (TitleLabel, FirstNameTextBox, ...).
In my company, we also do this, since it makes code written by co-workers (or by yourself a long time ago) easier to read (in my experience). The argument usually raised against doing this -- you have to change the name of the variable if the type changes -- is not very strong, since changing the type of a UI element usually requires rewriting all parts of the code were it is referenced anyway.
So, I'm thinking about keeping this practice when starting with WPF development (hmmm... should we use the txt prefix for TextBlocks or TextBoxes?). Is there any big disadvantage that I have missed? This is your chance to say "Don't do this, because ...".
EDIT: I know that with databinding the need to name UI elements decreases. Nevertheless, it's necessary sometimes, e.g. when developing custom controls...
Personally, I find that WPF changes the rules when it comes to this. Often, you can get away with little or no code behind, so having the prefixes to distinguish names makes things more confusing instead of less confusing.
In Windows Forms, every control was referenced by name in code. With a large UI, the semi-hungarian notation was useful - it was easier to distinguish what you were working with.
In WPF, though, it's a rare control that needs a name. When you do have to access a control via code, it's often best to use attached properties or behaviors to do so, in which case you're never dealing with more than a single control. If you're working in the UserControl or Window code-behind, I'd just use "Title" and "Name" instead of "txtTitle", especially since now you'll probably only be dealing with a few, limited controls, instead of all of them.
Even custom controls shouldn't need names, in most cases. You'll want templated names following convention (ie: PART_Name), but not actual x:Name elements for your UIs...
In my experience - In WPF when you change the type of a control, you normally do not have to rewrite any code unless you did something wrong. In fact, most of the time you do not reference the controls in code. Yes, you end up doing it, but the majority of references to a UI element in WPF is by other elements in the same XAML.
And personally, I find "lblTitle, lblCompany, txtFirstName" harder to read than "Title". I don't have .intWidth and .intHeight (goodbye lpzstrName!). Why have .lblFirstName? I can understand TitleField or TitleInput or whatever a lot more as it's descriptive of the what, not the how.
For me, wishing to have that type of separation normally means my UI code is trying to do too much - of course it's dealing with a UI element, it's in the window code! If I'm not dealing with code around a UI element, why in the world would I be coding it here?
Even from a Winforms perspective I dislike semi-hungarian.
The biggest disadvantage in my opinion, and I've written a LOT of ui code is that hungarian makes bugs harder to spot. The compiler will generally pick it up if you try to change the checked property on a textbox, but it won't pick up something like:
lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;
I find it MUCH easier to debug:
someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;
I also think it's far better to group an addCommentsButton with an addCommentsTextBox than to group a btnAddComments with a btnCloseWindow. When are you ever going to use the last two together?
As far as finding the control I want, I agree with Philip Rieck. I often want to deal with all the controls that relate to a particular logical concept (like title, or add comments). I pretty much never want to find just any or all text boxes that happens to be on this control.
It's possibly irrelevant in WPF, but I think hungarian should be avoided at all times.
I like using a convention (just a good idea in general), but for UI stuff I like it to have the type of the control at the front, followed by the descriptive name -- LabelSummary, TextSummary, CheckboxIsValid, etc.
It sounds minor, but the main reason for putting the type first is that they'll appear together in the Intellisense list -- all the labels together, checkboxes, and so on.
Agree with the other answers that it's mainly personal preference, and most important is just to be consistent.
On the need for naming at all, given the prevalence of data binding... one thing you might want to consider is if your UI is ever subjected to automated testing. Something like QTP finds the visual elements in an application by Name, and so an automation engineer writing test scripts will greatly appreciate when things like tabs, buttons etc. (any interactive control) are all well named.
In WPF you practically never need (or even want) to name your controls. So if you're using WPF best practices it won't matter what you would name your controls if you had a reason to name them.
On those rare occasions where you actually do want to give a control a name (for example for an ElementName= or TargetName= reference), I prefer to pick a name describing based on the purpose for the name, for example:
<Border x:Name="hilightArea" ...>
...
<DataTrigger>
...
<Setter TargetName="hilightArea" ...
I prefix any user-interface name with two underscores, as in __ so it is sorted before other properties when debugging. When I need to use IntelliSense to find a control, I just type __ and a list of controls displays. This continues the naming convention of prefixing a single underscore to module level variables, as in int _id;.
You can use the official Microsoft website for Visual Basic 6 control naming conventions, and perhaps combine it with the recommended C# naming conventions. It's very specific, is widely used by developers in C# as well for control names, and can still be used in a WPF or Windows Forms context.
Visual Basic 6 control naming conventions: Object Naming Conventions
C# recommended naming conventions in general: General Naming Conventions
Was talking to a colleague about XAML and how it is both a presentation and object description language and therefore quite unique and novel among IT technology.
Is this true that XAML is unique and novel?
Does XAML have any counterparts or predecessors in the Java world or elsewhere? I believe someone told me that Java Server Faces was similar to WPF, so what is the equivalent of XAML there?
I know MXML in Flex is similar but as far as I can remember there are some major structural differences, from what I remember MXML doesn't really describe objects but is more of a pure presentation XML.
This is a case of a general technology having such an overwhelming common specific usage that becomes synonmous with the specific usage. For example, discussions of Javascript often assume the browser context and the manipulation of a HTML DOM without anyone having to expressly say so.
Strictly speaking XAML is not like XUL or SVG apart from being XML. XUL, SVG have a defined syntax for declaring User interface or graphical elements, raw XAML does not.
XAML can, for example, also be used to describe Workflows in Workflow foundation.
XAML is actually an approach to reading XML in order to describe types and properties of those types. For example, a property of a type may be described either using an attribute or an Element as long as its name can be interpreted correctly. XAML also includes an extension to the basic XML syntax where { } in an attribute can act as a short hand for a complex element.
I've not come across this sort of thing before. All other XML based technologies come with a specific purpose, XAML is the first usage of XML I've seen that is deviod of any specific nomenclature but just a means of mapping XML to types.
****XAML, XUL, and XHTML Overlap****
The greatest overlap between XAML and other standards lies in its support for concepts drawn from HTML/XHTML. The similarities between XAML and HTML are numerous. Overlap with HTML is not limited to XAML, of course. The other well-known XML GUI dialect—Mozilla's XUL—also overlaps with XHTML. Finally, both XAML and XUL overlap in places that XHTML doesn't even include. XHTML and XUL can be combined in one document (at least in Mozilla browsers). Such a combination is a rough analog for non-Web uses of XAML. In fact, Mozilla's XUL alone is a rough analog for some uses of XAML.
but taken together, they really constitute nothing more than support for most of the basic HTML content and form widgets that are already routine in ordinary Web applications. XUL overlaps XHTML less that XAML does because XUL attempts to separate itself from XHTML. It's not trying to be a drop-in replacement, as XAML is.
One thing I do like about XAML compared with HTML is the increased freedom from the publishing-derived features of HTML. XAML frees you from h1 tags, code tags and a host of other miscellaneous niche tags used infrequently in HTML. For practical purposes, these tags act as little more than style information in modern HTML documents.
HTML is also a poor GUI for applications, despite the popularity of the Web. Both XAML and XUL go a long way towards rectifying that problem. You could re-write your Web applications in XAML and they'd look better than the HTML originals, if only XAML had better CSS support.
Read the comparisons to other presentation technologies with a grain of salt - Xaml is a method of constructing and composing .NET objects. That's in stark contrast to other systems that were designed as a way to build user interfaces. The nice thing about Xaml is that it's independent of the technology stack that its used for - it's a purpose-agnostic declaritive language more like C# than XHTML. In that way, it's unique.
Cocoa from Apple, or event earlier NeXtStep had something similar long before XAML.
The GUI is created with an interface builder, which makes so called nib (Nextstep Interface Builder) files, which contains the layout, bindings, actions, outlets and serialized object instances. In the former time these nib files were stored in a binary file format, but nowadays it is also xml (xib).
So XAML is not the first not unique at all.
Besides XAML, you have XUL which is used by Mozilla. SVG on the other hand, is one recommended by W3C.
Mozilla created their UI description language XUL originally to be able to easily customize the UI of all of their products.
Nowadays it's a package which can be included in other applications and also has an extended functionality.
Although XUL mainly focuses on UI representation it also contains other structures as Events and Scripts and Data sources. Nevertheless as far as I know XAML integrates these concepts much tightlier into their .NET (and attached) frameworks. But I'm not sure if this is enough to call it unique and novel.
XAML is an object graph construction language in the dialect of XML (not the greatest choice). Every XAML element is an object instantiation and the corresponding attributes are property assignments on said instance. Since XML is a string based language, property values need to be converted from their string type into whatever type the property expects. This is done using descendants of TypeConverter that the XAML processor locates and utilizes automatically. XAML and WPF come with a default set of TypeConverters corresponding to their provided types and you can provide your own.
A rough overview of the definition process is as follows:
<classG-in-namespace-A
xmlns="namespace-A"
xmlns:alias-B="namespace-B"
xmlns:alias-C="clr-namespace:namespace-C;assembly=assembly-of-namespace-C"
propertyG1="simple text value stipulation"
propertyG2="{alias-C:classH-in-namespace-C propertyC1=valueC1,..}"
>
<classG-in-namespace-A.propertyG2>
<alias-B:class-I-in-namespace-B propertyB1=valueB1,...>
class-I-in-namespace-B's content property value assignment
</alias-B:class-I-in-namespace-B>
</classG-in-namespace-A.propertyG2>
classG-in-namespace-A's content property value assignment
</classG-in-namespace-A>
There are utility types provided by XAML and WPF beyond TypeConverters that facilitate property assignments. In particular, there are the following:
ResourceDictionary,
ObjectDataProvider,
RelativeSource,
StaticResource,
DynamicResource,
...and more as shown in Microsoft Docs
Well, XAML is basically advanced markup for .NET, therefore I think you can draw a lot of parallels from XAML to XHTML - Both being presentation techniques.
There's a lot of differences as well ofc (XHTML being interpreted by a browser to produce graphics, while XAML is being compiled into MSIL and relying on the CLR to do the graphics :) )
This question is fairly straightforward -- I am trying to debug a memory leak in a silverlight application using s.o.s. I was able to get some good info using !gcroot to determine what objects have open references to the one that should be getting cleared; but in these cases they tend to be core UI elements (like grid and storyboard), and I can't really differentiate them without the ability to see the values of their dependency properties (like name). Trying to look through the dependency properties with !dumpobj is a total wild goose chase for me, they are all static classes (the properties that is) that reference each other and I just end up going in circles. At no point was I ever able to find a single actual value for a dependency property anywhere.
I googled about this quite a bit, but was only able to find other people asking the question, or speculation not leading to an answer. http://blogs.msdn.com/tess/archive/2008/09/16/q-a-reader-emails-about-net-memory-leaks-and-random-questions.aspx is one such page without answer.
Looking at the source of DependencyObject.GetValue in Reflector makes me think that this is non-trivial to do in Windbg. As an alternative (and a hacky one, I admit), in your own classes you could bind a standard CLR property to the Name DP, so that you do have a value that you can read in the debugger.