I'm after a link to online Microsoft reference doco for the XAML elements/attributes that are used in WPF XAML?
thanks
Such list would be pointless, because most tags can be used only in certain context.
All elements inherit from FrameworkElement class (though there are many more non-element tags, but these are usually used in specific contexts only), so you can look them up from there (though some of the children are abstract). Each tag's class page also contains information which tags it can contain.
Btw, IntelliSense is very helpful in this case. Just hit Ctrl + Shift and you get list of all the tags you can use in the context.
Also, you may want to check Expression Blend, it has siginificantly better XAML designer than Visual Studio (and it offers much more elements on the palette). And it works well together with Visual Studio (as long as you have corresponding version - Expression 3 vs. VS 2008 / Expression 4 vs. VS 2010).
Related
MSDN documentation specifies that when defining a custom control, one should define a control contract. From that page, it is so defined:
[TemplatePart(Name = "UpButtonElement", Type = typeof(RepeatButton))]
[TemplatePart(Name = "DownButtonElement", Type = typeof(RepeatButton))]
[TemplateVisualState(Name = "Positive", GroupName = "ValueStates")]
//...rest cut for length
public class NumericUpDown : Control
//...
I cannot find anywhere in the documentation where it specifies how to discover this contract. If I am overriding the control template, how do I know that I've handled all VisualStates, and that I've implemented all Parts?
This answer links to the same documentation, and provides a method for doing this with reflection, but that is not helpful at design time. Am I truly limited to essentially writing a console app that dumps the reflected attributes, or consulting the documentation (which may not be available for 3rd party controls)?
Am I truly limited to essentially writing a console app that dumps the reflected attributes, or consulting the documentation [...] ?
Yes.
Either you refer to official documentation or you have to find the corresponding attributes using reflection or find the template parts, visual states and properties by looking at the C# code and XAML resources. Even worse, while one should define a contract, not all controls do and in that case reflection does not even help.
However, most commercial libraries like DevExpress or Telerik offer a pretty good documentation for styling and templating. For WPF controls, you can extract styles and control templates via Blend or Visual Studio and consult the reference source in the worst case, if the documentation does not provide enough information. If there is no documentation and reference source for a particular library, it is guess or decompile.
I have made a FormBase, from which I inherit a FomBaseList and a FormBaseDetail.
All other forms in the project are derived from FormBaseList or FormBaseDetail.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs with the value found in FormBaseList.Designer.cs.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
This is a problem I ran into after upgrading, for unrelated reasons, from version 1.9.0 to 2.0.0 of the Extended WPF toolkit. Despite some time spent bashing my head against it, I'm still not sure whether the problem is with it, with my code, or just something no-one thought of at the time.
I had, previously, a PropertyGrid style that set up type-based custom editors for several different data types, using the TargetType property of the EditorDefinition. This obviously didn't work under 2.0.0, inasmuch as EditorDefinition is obsoleted, so, per the warning messages given, I rewrote the style using EditorTemplateDefinition and TargetProperties, thus:
https://gist.github.com/cerebrate/6695088
Here's the problem. If I comment out the upper two EditorTemplateDefinitions, those using the {arkane:Nullable} markup extension, the remainder of the style (the two definitions using the {x:Type} markup extension) works. If I leave them in, as soon as the window containing the property grid is shown, the application crashes with a XamlParseException, could not convert System.RuntimeType to IList.
The {arkane:Nullable} is a simple but pretty standard - or at least commonly seen - extension to TypeExtension to provide the ability to use nullable types in XAML:
https://gist.github.com/cerebrate/6695095
But more to the point, it's a simple subclass of TypeExtension and worked just fine when applied to TargetType in EditorDefinition, and hasn't been changed since.
Any ideas as to what part of the change broke this and how to fix it, on either end?
Or, alternatively, is there any way to associate a custom editor for the Extended WPF Toolkit PropertyGrid with a nullable type without using such a markup extension?
In Blend, it is possible to convert certain Xaml elements to Path, using Object->Path->Convert to Path option.
Is there some API to do the same programmatically, in a WPF application?
Thanks
Having dived into the source-code of Expression Blend with DotPeek (for research purposes of course), I can say that the Convert to Path API is not exposed in a useful way.
Internally it uses a number of private methods to convert RichTextBox content, TextBlocks, TextBoxes and simply geometry.
The only external method is in Microsoft.Expression.DesignSurface.Geometry:
public static PathGeometry[] ConvertToPathGeometries(SceneElement element)
But the parameter SceneElement is a type used only within Expression blend and has a huge number of dependencies. There appears no easy way to create SceneElements for your own Silverlight objects outside of Expression Blend. You could probably execute the functionality as a Blend add-in but I don't see you getting it working in a stand-alone application.
It was an interesting exercise, but unsuccessful. Sorry.
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 :) )