BasicPI

To get a feeling of the challenges with WPF I want to share the work to create a functional Property Editor in WPF. A Property Editor is a complex component, so it’s worth examining the challenges – that said – I am only exploring one path here – Both QML and WPF have multiple alternatives on getting this done.

The option that got my attention is StackPanel. In QML I just used a similar component and stacked 2 columns with label/editors. This will not work in Forms due to flicker on the screen, but it should work with WPF. To start I create a PropertyRow component consisting of 3 rows – a left, wide border, a label and a edit column. PropertyRow itself will just be a header as I extend the label to right, but I can subclass this into more specialized property rows:

• PropertyRowString – Edit a single line text.
• PropertyRowNumber – Edit a number.
• PropertyRowCheckBox – Edit a bool using a checkbox.
• PropertyRowComboBox – Select a value from a list using ComboBox.
• aso – the list here will grow.

The 2nd thing is to make StackPanel scrollable – woops that’s just setting a flag in StackPanel and it’s done.

The 3rd thing I would like is animation on the same level as in QML – if you scroll in QML it animate the action making the UI feel so more alive. This is not critical, but it is one of the details I really liked with QML, so I will look into how to get this in WPF as well.

As I have decided to use WPF “as is” with light colors and are not digging into Dark Theme I should have a much more free ride with WPF.

The first, early version showing only 4 rows of PropertyRow can be seen above.

This last pic show how the PropertyRow look in Visual Studio – somehow I missed the border lines only. At this point I must admit that doing this excact task in QML was easier. But, that might be because I know how to do this in QML and is a bit newbie on inheritance with XAML involved yet.

Adding a header row and manually adding a Scrollbar column the Property Editor look like below. I can work with this if I have to, but I think I can avoid the manual scrollbar – lets see later.

Having a good Property Editor is important for BSA. In QML I had no choise but to start making my own, but I have ended up doing the same on every platform I tried. In WPF I could get a free one or buy one, but do I want to?

My objects will have sub-tables and properties like description that is hard to do in any property editor + StackPanel can basically create a property editor using edit objects I can create allowing for an easy adding of custom editors. Yes, this is work, but the graphical editor and the property editor is key to BSA.

I have the same issue on the graphical editor. I could use a 3^rd party diagram editor, but my experience is that I will end up tweaking them because it is key functionality and is better off making my own from scratch.

So, in short – for Graphical Editor and Property Editor I will do it the hard way – from scratch myself – not because I want to, but because they are key to BSA and 3^rd party components might just be in my way.

This is a hard decision you better make up front. I have far to often spent hours tweaking 3^rd party components on critical functionality knowing that you have to be very selective. The question you always need to ask is If your application can adapt to the component, or if your component need to adapt to your application? In case of the later you need to be carefully.

A 3^rd component I need is a DataGrid with inline edit options – in this case I have no challenge with adapting to whatever I got to work with, meaning I will use the build-in DataGrid which is actually very good.

Another recommendation learned from hard experience is that you should select 3^rd party libraries with care, because you will have to live with them afterwards. Myself I often find it easier to create something I myself have control over than adapting to someone elses design and quality. But, again – I have never been afraid of putting my back into coding!

Designing my own property editor will probably also lead to another decition – I will systematically need to enable/create in-line editor options. I will use whatever WPF have and tweak it if I can or create new ones from scratch. The advantage is that I can re-use those for more advanced diagram-in-lines and I might get some 3rd party assistance. It is a lot of good developers out there that has released good solutions that can be re-used.

One of the hardest things you do in Windows development is to change the Title bar and integrate that better in your application. What you basically need to do is to switch off the Windows Title bar and create your own.

I have done this in Forms and Qt/QML, but WPF stunned me with how easy this was! One of the advantages with WPF and C# in general is the number of developers willing to share tricks and I owe this one to this YouTube movie:

[C# WPF Tutorial] How to Make a Functional Custom Window Chrome – EASIEST METHOD! – YouTube

This will work for dark theme as well as integrating the main menu into the title bar as I want to do.

The window above shows the modified, custom title bar with Menues moved into title. I only used some text for the buttoms, but I can now add whatever I want or set colors as I want in the Title. The importance of this is that I save some space at top + it is prepared for dark theme.

This is the WPF version of BSA after a few hours of work. It’s not much to look at, but I will focus on BSA itself and not the dark theme/cool look this time. Firstly I need to learn WPF so I can generate code for it anyway – but, I also expect to find a drop-in library that will change the look with a few hours work later. Lets see how fast I can catch up with 3+ months of QML work – that is the only thing that matters. So far I am impressed over how easy it is to learn WPF compared to QML.

Most of my focus is on SW for the time being, and it is sadly less interesting to write about yet. My BSA project is ambiguous specially since I keep switching development platform.

Back in the early days I did vector graphics on DOS. The challenge then was that you needed to even develop raster graphics functions yourself. My first 2D drawing was on Windows 95 using C++/MFC. That was a great success, but after that I basically stopped doing UI for a long time. I did a test using GDI+, Lazarus, Qt and even C#/Forms before I finally had a chance to work with Qt/QML.

Qt/QML is so far the best solution in terms of the result, but I am concerned that QML is so slow to develop with, so I want to try yet another solution – C#/WPF and .NET 5.

The main difference between QML and WPF in 2021 is that Visual Studio actually work as it is supposed to – it is a far better integration to XAML and C# than QML is. The debugger work properly and you only code in XAML and C#.

The second difference is 3^rd party libraries. In QML they are expensive if they exist at all, while in Visual Studio you have access to ca 235,000 libraries with a single click.

Something that is not different is that you need to modify a lot of controls to have a dark theme etc, but you have the advantage that it’s a lot of 3^rd parties that has done this already.

My WPF version of BSA don’t look as cool as my QML version yet, but just wait.

I have coded in C# before and was tempted to develop BSA in Forms since .NET 4.6.2, but .NET 5 and WPF seems to be much faster to work with than QML. My QML version is not lost because I will generate code for QML regardless. And I need to generate code for C#/WPF .NET 5 as well. And don’t worry, I will pick up Lazaruz as well at some point.

This simple drawing illustrate how I can create a gauge with several separate layers. In this case I draw a background and a needle on top of that. The final gauge is illustrated at top. This is exacly how I plan to embed a gauge editor in BSA – by using a table with x layers where the user can draw (or code) each layer separately and watch the result. This is an easy way of creating gauges where you also can use gauges within gauges.

In this example I scale the rotation of the needle so that input value match the scale. But, I could easily rotate or change something else – meaning we create a system to scale input values to position, rotation etc so we can animate any part of the gauge. It’s a few details I need to experiment with, but gauges are important in my worlds and this system should allow you all to create your own gauges easely.

Once created the gauge should be visible in the toolbar and be available for usage – which means I need tp export properties to make a consolidated property list. For gauges build this way I plan an in-line editor where you can create local adaptions or modify the library directly from the place you use the gauge. I think this will be awesome, but it will require some experimentation and try & fail adaptions as we go.

This is just an auto-generated demo (new application) using Visual Studio/MFC. I use Visual Studio Community so you can download this and try for yourself. I switched from DOS to Windows back in early 90’s using Windows SDK and C at first – I remember the day I got my hands on Visual C++ 1.0 and the first version of MFC – it was a big difference. The best part was the debugger that set a new standard.

The content of the views about are demos – not functional, but the components are very real. You see a TreeView at left and a very good Property Editor at left + what you don’t see is a very good docking system. The app mimic an earlier version of Visual Studio.

Graphics in MFC is GDI by default, but you can use GDI+ with a trick – meaning modern precentation graphics through CPU.

Comparing MFC to Qt I would chose MFC any day, but Visual Studio only have C#/WPF that can compete with Qt/QML.

And as for MFC – I have used this for years as a Windows GUI developer, but it is few that uses this today – firstly it has a steep learning curve so few know it. But, Microsoft don’t focus on this anymore sot it is more or less abandoned. It does not receive the wealth of new components and infrastructure as .NET does.

Comparing Qt/QML to .NET/Core + WPF – I don’t know. C# is much easier to develop with than QML, but I have never dug into the WPF side. The reason I currently work on QML is the access to the GPU’s. QML is easy to work with on graphics, but bindings to C++ makes it difficult unless you want to develope everything in JavaScript. The main drawback with QML is that you don’t get a flying start as the one above – but, that will change soon.

MFC brings back many good memories about things that worked as expected – I will not claim that it is easy to code in, but it is no worse than Qt to be gentle.

The challenge however is that this is Windows Desctop only and for that it is great – but, applications these days needs to be precent on Web, Windows, Linux, iMac, tablets and phones – and it will be interesting to see if Qt/QML delivers on those.

The demo above have some important learnings – Wizards & Templates to get started is worth a few days, but their not the ones getting the job done as you work day by day, month after month on a system. The Property Editor is a good source for ideas, but not everything is perfect. I will do better. As for docking system – Wait & See.