xsharp.eu

Hi folks,

In other threads we have been seeing how XAML script can be used to represent the state of a WPF form at application 'start-up'. And how it can be used to simply define the initial state - by 'mark-up'.

Well, it took me quite a while, after starting to use XAML, before I realised that some (or much) of my confusion (or uncertainty) with XAML was due to it having the syntax flexibility of a human spoken language. There was often more than one way to do things in the XAML editor - short cuts and the likes.

I would like to start to discuss some of the syntax variations with you so that we can make more sense of other peoples WPF samples that we find on the web.

Recently we looked at the Button control and discussed how it was a 'Content' control - meaning that it had a 'Content' attribute (property) which could be assigned another control object.

Lets look at a common way to script this - check the following image :-
What we said in the previous thread was that 'content' could be placed directly within tags, and not mention the name of the attribute (Content) at all. This approach is often done for content controls other than Button, but the following is correct and acceptable - check below :-
But lets look at another way to express our syntax - one which produces this :-
The syntax used is shown below and in many ways is based on the standard way to define an attribute/property :-
By saying that the above XAML script is a common way to set attribute values, lets write the script for a pretty standard Button in this way - YES ! , it may seem a little odd to you BUT it is correct ;-0)
Now then folks, check to see that each of the pairs of tags represent a single attribute and that its value is within the tags.

This is not the way we usually see Width and Height being specified but it is one of those syntax variations we need to be able to read and understand. Check the above out carefully!

Enough for now, lunch is ready ;-0)
Speak later in a follow up to this thread, when we look at something a bit more complex, and the code to go with it as well.

Regards,
Phil.
Wales, UK.

Hi again guys,

Well then, lets explore this topic of syntax in XAML script a bit more, and learn some more fun things.

The following image is one of some interesting XAML script I found in the MSDN notes, and wondered just what the deep nesting meant.

Don't panic about not knowing what it all means, I felt the same 90 minutes ago ;-0)

Study this deep nesting of the XAML script :-
So just what does this mean, are any of the nesting settings 'Content' or 'Items' objects ? Or are they something else ?

To help us understand what we have we must look at the Document Outline (DO) pane, seen in the following image :-
Well then, that is a surprise, the 'DO' content would clearly suggest that we have a Grid control in the Window form, and that it has only one object within its children, and that object is a 'Path'. And it is in the System.Windows.Shapes namespace. Path is not in the full toolbox and so we will not call it a control or tool.

So all the nesting must be about using the nested tags to specify property values (attributes). I decided to find out more simply by making myself create the same shape (and screen output) but using X# code instead of XAML script.

First I commented the Path script and gave the 'Grid' a name :-
And then I did a bit of my usual trial and error fumbling, until I got some code which compiled AND produced the correct runtime output - check below :-
Yes, all we are doing is making a bunch of objects - six in total - and then assigning five of these to properties of the other objects. Obvious 'myPath' is the root object. And 'YES' it does take some effort to start to get our heads around this code. But its not rocket science.

This means therefore, that all of the script 'tag nesting' was about attribute assignment, or giving properties suitable values.

Obviously, I had to comment some original code and script because the new stuff is to create the same result at runtime. He is what I did :-
Now then, before I go I would like to leave you with some MSDN code which got my "foot in the door" as regards the Path problem above. Once again it is to do with 'Shapes' - check this out :-
So we can draw the conclusion that we can place Shapes in a Grid control in a similar way to that which allows us to place controls from the toolbox.

I need to do more work with Shapes, as most of my XAML / WPF time over the years, has been spent on Data Binding and SQL data sources, and Entity Framework. Shapes look fun.

Enough for now, time for a nice cup of tea ;-0)

Cheers,
Phil.
Wales, UK.

Good afternoon X# guys,

Lets take further our exploration into the syntax variation for describing the layout of our WPF forms.

So far in previous posts we have seen that WPF form layout can be achieved using XAML script and/or X# .NET code. We have also seen how in XAML script we have some interesting syntax variations - meaning more than one way to construct the script.

However, we have seen that there is almost a 100% correspondence between classes and their properties in .NET namespaces and XAML namespaces. So which we use in code and/or script is NOT a confusing issue.

Let us now look at some more of that interesting 'Shapes' namespace stuff - this time we will draw a circle and an ellipse, oh! and because we end up with a Path object we can assign it to the 'content' of a Button control.

First of all lets see the image at runtime :-
Yes, the WPF form output is actually two push Buttons, as the blue colouration of the hovering mouse pointer would indicate.

So the Shapes have effectively been attached to the Button surfaces.

Lets now see the .NET code for using X# to do this - we really have two almost identical sections of .NET code - check below for details :-
Now then, lets make an effort to translate this code into the same effect script in the XAML editor. Remember the key is to realise that the object classes are similar, and the assignment ' := ' symbol / operator is a pair of tags, the object being assigned is represented by the content between the tags.

Okay then folks, lets study the XAML script for just the ellipse shape - see below :-
As you can see, it works as we may have hoped - AND - we have effectively attached the shape to the Button control - see lines 48 and 55, the Button tags.

Now then, for those code guys who like tidiness and code order, and stuff lining up in the editor, here is the same script - study the details :-
I have to confess that I am not in the habit of converting code to script and script to code, but I am getting better at it - its an acquired skill ;-0)

I also have to confess that for some of the initial form specification, I prefer the XAML method, to me after years it seems to make more sense and is often easier. But this is quite a personal issue, so find one way and use it, then acquire further skills by branching out and gaining more skills doing it the 'other' way.

Now then, must rush as family is just about to have lunch ;-0)

Speak later,
Phil.
Wales, UK.

Hi Phil,

may I be a bit provocative?

To make the entire thing correct, the parameters of the ellipse should be data-bound - in good MVVM style.

That should be possible in XAML code (but please don't ask me how <g>).

Wolfgang

Who ? You ? Provocative ??

Never ! ;-0)

Simple answer - 'one step at a time ... please'!

The current thread 'theme' for me as author / provider, is simply to look at syntax variations, so that all of us guys can read and understand better what we find in web articles.

What I am showing is what works, not at all the way I would do things in an application that I was creating.

I will have a think and a play around with data binding.

Thanks for contributing your ideas - always good to have the thoughts of others.

Regards,
Phil.
Wales, UK.

Okay then Wolfgang,

A good challenge indeed - lets call it the Easter challenge !

According to the eNotes I provide others with then Data Binding is all about Public Properties. If we bind our XAML attributes to public properties then all will work A-Okay. Lets give it a go.

Lets take each and every attribute in Button and Path objects on the Designer surface and provide a binding - except the Name, but that could be done as well if we so wished.

Check out below how each value has been replaced by a suitable, and named binding :-
And before we go and checkout the X# code, lets first see the result at runtime - see the following image :-
Now then, just run your eyes over the public properties, their names and their initially defined values :-
Finally, this is NOT where I would normally place the public properties - these would normally for MVVM pattern of development be in the ViewModel which would be a separate class object which is assigned to the DataContext property of the View. The Window object we are dealing with is actually the View.

Does this answer some of the questions Wolfgang ?

Cheers,
Phil.
Wales, UK.
Regards,
Phil.
Wales, UK.

Hi Phil,

for Easter it is a bit early.... We have a full week to work until then....

Now, this makes much more sense to have databound properties than hardcoded ones in the XAML.

Thank you very much!

Wolfgang
Meran - South Tyrol
Italy

(SCNR)

Hi again Wolfgang,

The challenge you set me was an interesting one - BUT - it is not really what I would normally do.

Remember the phrase "... with a hammer in your hand everything MAY look like a nail ...", well this applies I feel to attributes on WPF/XAML controls and objects.

In WPF there are many, Many, MANY, attributes which can be involved in 'Binding' but that does not mean that they should be used this way, just because they are on a View, or form. They are 'Dependency' properties/attributes, and only these type can be 'bound'.

To me, I focus on the 'Data' aspect of the term 'Data Binding', and make sure that by using the MVVM approach I bind my business data to the relevant parts of a WPF form.

I also put all my support X# code in the 'ViewModel' class, where I have lots of Public Properties (PPs). Many PPs are to do with the 'Model' data been passed into the constructor of the VM, and some PPs are made and kept within the VM class itself, simply to support the working behaviour of the 'View'. A classic example of this is the 'SelectedItem' public property I would bind to keep track of what has been chosen in a list or combo box control - attributes are named 'SelectedValue' and 'SelectedItem' and are dependency properties/attributes. This removes the need for selection to be driven by UI events.

Now then, I also feel that there is not a design problem with actually specifying fixed numerical (or other) values in the XAML mark-up, if these values are just needed to set up the Form / View.

We need to remember that 'Binding' is all about giving the user access to data deeper behind the visual display layer, so that there is no need to move values from one class instantiated object, to another. Why move data values when we can bind to the original data objects ? And what is wrong with specifying that the width of a Button is 120 ? Not all Buttons, but most can be hard coded I feel.

So in many ways what I did previously, with circles and ellipse objects on the Button surface, was an interesting challenge BUT not something I would normally think of doing in my Form design.

And also, when it comes down to it, If I want more fancy and complex controls, I would buy into a Third Party product, Like DevExpress or Infragistics, where others more able than myself have done all the fancy and correct stuff.

I see my role as developer as the guy who gets the business logic and business data 'flow' correct in my application design.

Hope this helps and interests a few.

Regards,
Phil.
Wales, UK.
P.S. ... feeling a bit helpless without my SnagIt app working ;-0((

Hi Phil,

of course it would be possible to set the button width by databinding, and I would do it only when the user could change this width as in a datadriven application, or if something in the application logic should compute this width (but I hope to never need this).

IMHO the logic behind graphical objects in a business application most often is that they are data-based (i.e. based on data from the application), and therefore I would databind these dimensions.
Of course, if an ellipse is a pure graphical object, databinding is contraproductive.

Wolfgang