xsharp.eu

Hi Nick, and all other guys,

Following recent discussions in other parts of this Forum is would like to clarify and cross-check a few things with you Nick.

Although it is many years since I did my WPF session in DevShare on a code only basis, I seem to remember that both XAML and code can be used on the same form - is that right ?

I will do a test in a short while - BUT - for now lets say (ask you) that the 'mark-up' part of XAML just sets out in a once-off static way the details of the form surface.

Once the form exists then as application code runs the form can be changed in any/many way(s).

We all know that no runtime logic can be included in the XAML, since it is 'mark-up'.

The code that Wolfgang so helpfully showed us can be done possibly more easily in XAML - but, I do realise that he does a lot more.

My question to you Nick, is can he do both - and initial Mark-Up and then some runtime code.

I feel some fun testing coming on.

Do you think that readers of this Forum realise that when creating a new WPF form that experienced guys may do much more with typing script that the interactive designer and toolbox?

Please send us your ideas and opinions.

Regards,
Phil.
Wales, UK.

Sorry guys, my typing seems to be well under 'par' judging by the Subject heading I first posted ;-0((

Now then, results of some testing on this topic area :-

I seem to be easily able to mix both XAML script from the Designer / Editor for WPF, with code hand entered into the X# code editor (manually). I had to re-learn how to add my children controls / GUI objects.

First some quick and simple stuff via the Designer :-
The top most window (layer wise) is the live results at run time. Note that some changes have taken place from the form details marked up in XAML. Some sizing and a bit of text.

Now then, a more specific and detailed bit of X# code which adds a couple more controls to the same (and single) Grid that was used in the XAML script. (Called by me 'Main' grid.)

Check this out :-
Yes, a change of colour to the XAML button, and an extra button (green) added to the main Grid along with an empty DataGrid control. OK, nothing flash about it.

Notice that I have defined 'Names' for each UI element in XAML and in code. And I have then used these to simply do what I needed to - identification wise.

Check out lines 21 and 22 since this is where we first apply the XAML script, and then to the existing window add other controls to the main Grid. It has to be done in this order when done this simple way.

This is just a simple and straight forward start - BUT - it feels to me as if we could do much more complex stuff, with both code and script. Anything we like really.

Remember though, XAML is just mark-up, if you wish to have a 'fluid GUI' in any way at runtime, then the code section has to do that for us.

However, for many WPF forms, for many types of Form, and for many guys, a static mark-up with bindings set in the XAML script is more than adequate. I use this style all the time for my apps.

Nothing wrong with code - BUT - I find it much quicker, easier and less typing to add script and not code.

If you are doing data driven UI stuff like some guys, then the design happens at runtime so code it is for them.

Hope this interests a few out there. Oh! you may be starting to feel how simple the WPF design really is. There is nothing hidden that we need to know of. The classes and attributes on the XAML side of things, almost 100% matches those for the code side, where attributes are called properties.

My point to Wolfgang and Chris is that if we could use the Blend GUI design surface to generate the XAML then we may some way be able to transfer that over to the XIDE side of things. Effectively using Blend as XIDE's WPF designer. A bit like the VS designer for WPF does for the X# projects I make.

Blend is an improved Designer on the VS one, but to be fair, it is very good, and just about all I have used over the years.

Yes, would you believe it, in early days the Vulcan app would load into Blend, then along the line that capability stopped ;-0((

Hope this interests a few,
Cheers,
phil.

Okay then guys,

Just tried it and failed - Blend 2017 will not open the project I was creating and testing just there now in VS 2017.

I don't know how much work would be involved in allowing us X# guys to start a project for X# in Blend and just create the WPF forms with their attendant XAML script.

But it could be seen as an external Designer to XIDE if it were to be made to work in some ways.

What about some alternative strategies - writing translators for XAML to code and code to XAML - they are very one to one correspondences !!!

See you tomorrow,
Phil.
Wales, UK.

Hi Phil,

of course you can mix XAML and written code, and you can even use VS or Blend to generate DLL from XAML code and use these views then in your XIDE application - I had a few samples for this, as I tried it first.

But please give a look at my code: I had only points in the entire view where I set a dimension, and that only to two of the Grid columns. All other dimensions are calculated at runtime by WPF, and that is the real great thing!
With WPF you have the power to create the highly dynamic forms that are caracteristic for web applications and modern desktop applications.

Of course you can write manually XAML code, but then I prefer to write X# code.

And of course for every XAML statement you will find the corresponding .NET class and property because the XAML code at runtime IS translated to .NET code. XAML is only a possibility to configure .NET classes in a markup language, ideal for a designer that knows HTML and/or XML.

And yes, of course I had the possibility to use also my own control classes in XAML, but I prefer the code.

Even if I don't write datadriven windows, such a code is normal in my applications (pseudo-code):
and such code is impossible to write in XAML.

In my VO-Applications the windows are designed in the WED, and some controls hided at runtime, creating unused space in the middle of the window, or reorganizing the controls on the screen. In my new application architecture, unused controls should not be created, and with XAML this is not possible. With MVVM, this is easily possible.

Wolfgang

P.S. of course, even in a code-only application, you can load stylesheets or other XAML code at runtime and execute it.

Wolfgang,
objection, Your Honour!

Wolfgang Riedmann wrote:Hi Phil,

and such code is impossible to write in XAML.

That's wrong. I know you don't like XAML, for whatever reason. But once you take a deeper dive into XAML and its possibilities you will learn how flexible and easy it is. In this context look into Styles, Templates, Databinding (TemplateBinding).

Regards
Meinhard

Hi Meinhard,

until now I have not found any possibility to build XAML forms depending on the configuration. In my case this can be defined by the underlying data, by the connected user or maybe by the customer that is using the application.

Wolfgang

Hi Wolfgang and all,

There is another alternative which needs to be discussed, and that is using the runtime logic of X# code to swap in/out UserControls (UC) to ContentControls (CC) on the WPF form.

Nick and I use this a lot in some of our samples we made publically available.

For myself, I designed the UC's using the VS 'design surface' (UI and XAML text editor) and then when logic dictated it assigned to the 'Content' attribute / property the appropriate UC.

If we really whished we could add UCs to different CCs depending on business logic at runtime. So that the same UC does not always end up in the same CC.

The general approach of ".. painting by numbers .." is not what many guys would wish to use. Or put it another way, there is a definite need for some sort of a WPF form designer. Whether we as coders use it or not.

My personal opinion is that if I do not have access to a good UI designer tool for WPF in X#, I would have to go back to using C#, which I hope I don't ever have to do ;-0)

To me its the same argument as that for LINQ, or not.

Did you ever use the nice 'WinForm' designer in Chris's VIDE ? I liked it a lot, but it did not have to deal with the issue of 'nested' controls - something which does add a large overhead I feel.

Wolfgang, have you ever used "Aldus Pagemaker", and/or AutoCAD ? Not easy to get into but necessary to exist and be used.

Having asked that, guys should also realise that the WPF designer in VS can be used very sparingly on the drag, drop, rearrange, resize, way of doing things. I tend to drag or copy a tool from the toolbox, onto the form and then do a lot of XAML text editing (manual typing) - its much quicker.

If I wanted six buttons, I would drag onto the form one from the toolbox and then copy the default XAML script/code five more times in the text editor, then make a few adjustments. I would not drag six buttons from the toolbox - that's just my way of doing it.

There are many ways to use the Design surface, and we can make it VERY personal indeed.

One thing we have not even mentioned in our discussion on WPF design, is the use of Grid lines, and placing by typed attributes and their values - control objects/items within the Grid. And as always we can have grid lines within a single grid box, ad infinitum if you so wished.

I wrote some eNotes many years ago on the details of XAML and using the Designer in VS, find these at :-

http://www.winclickstartvulcan2.net/Web ... tXAML.html

Here is the best I could find this morning (on grids) :-
If you find some time to look through it guys then I think you may pick up some tips and stuff. It took me a LOT of effort to put together, and in some ways it looks or is a bit 'dated', but it should still all be true and correct.

I was looking for my example of a Grid with lines, within another grid etc.,etc. - but failed to find it. It is somewhere in my various eNote volumes.

Hope some of this stuff rubs off on you, it's always handy to have in your knowledge / skill-set, just in case.

Regards,
Phil.
Wales, UK.
http://www.winclickstartvulcan2.net/Web ... tXAML.html

Hi Phil,

I agree that a sort of window editor is needed. But the highly dynamic structure of WPF makes it hard to build one.... IMHO a tree would be the correct implementation, maybe with a preview pane.

I don't know any serious web programmer that uses some sort of GUI editor for its forms - all the people I know are working with text editors with some syntax completion for PHP and Javascript.

And I have discussed more than once with Chris about the possibility to build a window editor for WPF that works very well, but unfortunately I'm very busy with my own projects and Chris is very busy working on X#...

For sure, my mode to build WPF windows is my own solution for this problem, and cannot be the right choice for everyone.

Wolfgang

Hi Wolfgang,

At least you have a good solution which keeps both you and your customers happy. That's important ;-0)

My worry as a teacher is that many guys may NOT find a solution simply because the don't know the few things, and a few tips and tricks, to make the Designer in Visual Studio work for them.

I have been at it so long I almost forgot the early days of frustration and my errors. Dick has kindly reminded me in the post on the news group. I will use these in a Forum response tomorrow.

Forgetting Blend for a moment, the WPF Designer in VS should do most folks, most of the time. Once you know how to use it, it is really quite effective.

Here are a couple of taster images - of nested Grids with grid lines, and a button which is hardly visible at runtime. Getting these controls nested can be tricky indeed if we do not use the zoom tool correctly, and the Document Outline pane to check the placement in the visual tree.

Thanks for chatting,
Phil.
Wales, UK.


P.S. I did not colour the yellow/blue guide lines ;-0)

Hi Phil,

I agree that the average VO programmer needs a GUI form editor, but IMHO he needs much more: many, many VO programmers (including myself) have used the SSA (South Seas Adventure) sample as starting point for their applications.

Such an application is needed also for X#, but I have my doubts that a WPF/MVVM application is the right start, maybe a small WinForms application is better as starting point.

But apart from these, I expect that a lot of VO programmers (including myself again) will move their VO programs to X# when the runtime is finished and the WinForms based GUI classes are available. In this manner WinForms windows can be integrated into these applications very easily.

(I simply cannot stop my VO development for a few years and move the applications to .NET - I need a simple migration, and only X# can offer this).

Wolfgang