xsharp.eu

Hi guys of the X# forum,

I am starting this thread as a result of me being aware that some / many forum readers seem unfamiliar with the strengths and complexities of the Designer for WPF forms - within Visual Studio.

I have been using the in-built designer / editor for many years and I see that the first image I will show you was done some time around 2010, latest possible date of 2012. Yes, its 5 to 7 years old - lets call it SIX years for simplicity.

Before I show you this non-trivial WPF form, let me says that to get the best from WPF design, we need to take firmly on board the fact that it is a 'nested' design, where we have control objects within other control objects and so on as deep as we like. This is what causes most folks the problems they report, and get frustrated over.

Okay then, lets take a look at my Invoices screen, shown at 'DevShare' 2011 I believe :-
Yes, there is a lot of detail, even though I was no expert, and don't profess to be one even now.

In fact what we have is four Grids within an outer Grid. We can see this by opening up the Window called 'Document Outline' - check this below :-
This is to be found under 'View >> other windows >> document outline' - or Ctrl+Alt+T .

Now then, as with more complex designers, like those in DTP (desk top processors) and AutoCAD drawing type tools, we can have locking and hiding of screen elements, to make work on other parts easier. Lets see some images of Lock and Hide :-
As you can see in this last image, the one just above here, we have turned off, or hidden some of the form's sub-objects. In this case two Grids and a push button.

And YES, we could turn everything off to make a blank screen, without destroying our previous work.

Try this for 'size' - meaning in UK parlance, "what do you think of this ?"
And we can also lock the whole form quite simply by one click - see below :-
I think this is enough for this post, I will continue in further posts where we can examine other aspects of the designer / editor features.

Here is a taster of what is to come :-
The size is set at 6,400% - as we can actually manually input any size we require.

Cheers, and Best regards,
"Learning is fun",
Phil.
Wales, UK.

Hi again folks,

Lets now look at some other features of the WPF designer - some sizing and some snaps and drawing reference grids. Not to be confused with the Grid and DataGrid controls of the WPF form.

Previously I said we could free hand enter a size for the designer display - well that is true - BUT - it is then converted by the system to a suitable size as close to that entered. There is a maximum and a minimum, see below :-
Yep, not a lot of good to those older guys needing reading glasses - I type 1% and got 3.13%

And what about this ? :-
Yep a cool 1000% or ten times zoom I suppose.

Lets now look at the small Designer Control area where we have a few useful controls :-
The size control is obvious and to the very LHS top.

The others do some useful things to do with drawing grids and snapping etc. - take a look :-
And then we can do a couple more things, and important one being to Disable the Project Code - this temporarily halts interactivity between script/code and design items.

Check these :-
Finally for now, and in preparation for the next post on the Designer, we need to mention 'Granularity'. If we have our designer at too small a size (magnification) then sliding tools from the toolbox onto the design surface gets unpredictable.

The problem is when the edges of the control being dragged, touches or overhangs a Grid edge, it may (when released by the mouse) fall into the wrong nested grid. Its all about size and placement - AND - using the DO (Document Outline) pane to see into which sub-group it has landed, or ended up.

Lets leave things for now, and also say that the Designer has some wonderful features, once we know they are there, and how to use them.

Regards for now,
Phil.
Wales, UK.

Hi guys,

I have looked a little bit deeper into the possible differences between the facilities in Blend 2017 and Visual Studio 2017 - as far as WPF form editing and design is concerned.

The most obvious difference can be seen in the next few images, and is to do with Blend having guides, that can be set, moved and locked.

Here first is the Design menu options, first in VS :-


And now the longer menu in Blend :-
Now then, if anyone has not used DTP (desk top publishing) apps before, or perhaps Sketching/Planning or Engineering design tools from "Autodesk" (in the past), we can see Guides in place and locked in the next image of Blend 2017 in use :-
We can even save and load previous Guide settings.

Now then guys, you may have heard of 'layers' with some more complex design tools / apps in the past (for specific stuff like electrical services, water, gas etc.) - well, we can in Visual Studio do something similar with Grids. A WPF form must be based on at least one Grid - this accepts other controls as children. The main Grid is usually within a Window or a UserControl.

Look at the following situation, and hazard a guess as to what is happening :-
We have one main Grid, which is grey, and four other Grids which are within the main Grid but NOT nested within each other - the next image will show this :-
I know that the Grids sizes and positions are not realistic, and could be better, but they serve the purpose of demonstration. We can now place other controls within each and any one of the Grids, BUT, the big thing is we can Lock & Hide those grids we don't wish to be working on. So we can't change or 'damage' their design as we do other new work.

The 'check icons' to the RHS of the lines in the Document Outline are where we hide/show and lock/unlock. very easy to use.

Now then guys, don't get mixed up between the Grid lines of WPF (available in both Blend and VS) and the drawing 'Guides'. Guides belong to the Blend design surface, and grid lines belong to the WPF specification. Some may say they are just in-built WPF guides, and they would have a point ;-0)

Below are standard grid lines for making rows and columns in any Grid container on the WPF design GUI surface :-
In order to have the grid lines as shown, we must have nested grids, that is a grid within a grid, within another grid. I have made the smaller grids the size of one higher grid cell in my example. It could be otherwise, depending on your requirements.

Enough for now, lets hope this interests many, and lets a few more guys learn something new. I know I have learned a few new things in researching what I have just posted ;-0)

This stuff is great fun!!

Regards,
Phil.
Wales, UK.

Phil,

Thanks for the explanation.

Chris and I are working on moving a Harbour UI to X# - WPF. Since the original app has been designed for a 25 x 80 DOS UI the most obvious choice for now seems to be a 25 x 80 grid.
Fortunately you can use colspan to layout controls over a group of columns. Very convenient.
Of course the challenge then is to make it "look good".

Robert

Hi Robert, (and all)

If you are to map the old 25 by 80 character grid of DOS stuff to a WPF form, then maybe the Canvas control in WPF is your answer !? Its worth a good hard look I feel.

Now then, to a topic I wish to discuss today regarding the nested structure of WPF form contols - the tree structure of their controls.

One issue that makes the WPF Form designer more complex to use, is the fact that we have in WPF, some control which are said to be 'Context' controls. There are a few, and not all of them are similar ;-0)

Basically, some controls are designed as containers - meaning they can hold other controls. So the obvious one is a 'Grid', which can hold a whole bunch of children - many other controls.

However, some content controls will only accept a single item as their 'content'. Examples of this are 'Border', 'GroupBox', and 'ScrollViewer'. Below is an example :-
We can now see the issues, shown in the editor, if we try to add a second control to any of these - check the following three images :-
Yes, the above editor warning / error messages tell us that only one CHILD can be contained by Border, GroupBox, and ScrollViewer.

But in the next image we see a single 'Canvas' object as contents of the ScrollViewer, and the Canvas can have many children - here is the "Document Viewer" information :-
Now then guys, what are the special controls allowing us to have a list of controls (many) or as we say to have 'Children' ? Well, lets start with 'StackPanel' and 'DockPanel' for a start, these are designed to help displaying other 'stuff'. They are great for data templates!

Lets add some panels to our Canvas object :-
And to the 'DockPanel' lets add a new control to us in this sample, the 'Calendar'. Below is the GUI and the text in the editor :-
So then, this all makes sense BUT how does it help us understand problems of tools dragged and dropped from the toolbox ?

Well. depending on the designer settings, hide/lock and zoom etc., we could end up trying to 'drop' the dragged control into a screen area which is inside a Content Control. However, the most likely problem is us thinking we are doing a drop but in fact the outside of the control actually overlaps with an existing displayed control, so drops into a different 'nest' place. This can be hard to see visually, and where the dragged control ends up can be NOT where we would hope.

The above works better if the zoom is set high, and we have enough room for the mouse pointer etc., etc..

Like all IT stuff, it is easy once you know how it works, and know what is happening ;-0)

The Designer is not just for trivial form layout, and it can be used (quite easily) for much more complex form layouts - but the 'content' part of some controls has to be handled property, as well as being understood. Old guys may thank Aldus PageMaker !!! for their learned skills.

Oh! - do not use 'Canvas' unless you need it, and know what it does for you. It was an early tool in the WPF toolbox and was used before Grid. "Keep away", is a simple piece of good advice to most guys. The coordinate positions are absolute.

Firts reach for the 'Grid'.

Hope this interests and helps a little,
Cheers,
Phil.
Wales, UK.

Sorry guys,

In one or two places ... for 'Context' read 'Content' as applied to controls.

Phil.