BasicPI

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.

Setting up all the colors needed for controls is actually a bit of job because you need a set of colors for (1) Normal display, (2) Mouse Hover, (3) different states. In this case I show a button so I need Pressed. And for each set I need background, text and border etc. So, if you see only a few properties now – just wait.

I need all the properties available, but at the same time I don’t want to fiddle with them. So, what I will do is to set up a Palette system where you chose the value “Palette” meaning that colors are preset in a global paletter that support global themes. So if you want to change a color you can either change the Palette – in which case you change it for all objects, or you can set the color directly as shown above. In the later case you change it for “this” control only. But, at the end of the day I just want to drop in controls and not worry about fiddly details like colors – I just chose a theme for my application.

My previous entry raised the issue about how to edit multi-line text. The illustrations below show one possibility.

In this case I illustrate a description – something I want on every object. This is a normal property, but since it is a multi-line text it servers little purpose to display it on a few characters like a normal property. A possible solution is shown below.

As you expand the property to edit it I can pop out a small mini-editor to make it easier to edit this exact property type. As editing is done we collapse it back in. The only drawback is that we now need to expand the text field every time we want to read it – which make it less available/readable. But, it’s an idea.

This shows the Note – the Note is a tool allowing you to write text with a Note border around it and it can be linked to obkects with lines etc – a handy way to make comments.

However – how do we edit the note? (1) display the full note, while (2) display the property editor version – ok it will look better once I allow multi-line text in the editor, but that is not the point – how should we edit the content of that note?

The answer is straight forward – directly in (1)! Double click on the node and you go into inline edit mode. This is one example where editing in the Property Editor makes no sense because an inline editor will be so more awesome. And even better is that while we edit we can as well show specialized text tools and even capabilities to add images inside text etc.

Don’t worry – you will hear a lot about the Property Editor. The one you see above is yet a simple one. I am still using string edit for colors, but it works fine due to the nature of JavaScript. JavaScript accept colors in string format by name or #xxxxxxxx. (ARGB format). I will add a proper dialog option for that later – but guess what – I wait for BSA to generate that dialog for me 😊.

The top 3 lines for each HMI object will be standard – a display of what control this is, the local name and the full name – currently you see the full name only. The name of the control is “edit1”, but since this is located on “form1” you get “Form1.edit1” – or more correctly “From1…” since I have a spelling error 😊.

I currently lack a lot of properties here like x,y,width,height etc. I will also need options to expand category trees and sort properties. And well – I did mention specialized edit dialogs.

One of the most wanted is actually a multi-line text editor. I want this to expand using the full width so you get a mini editor and optionally expand into a full window if needed. Adding comments and having proper tools to do so is important.

The Property Editor is important because it enable me to easily and uniformly edit all details of a diagram. The alternative would have been to create dialogs for everything and use double-click etc. With a property editor you only select the component and change properties watching the changes apply as you change them. A Property Editor is however not ideal for every property – descriptions etc is one of them, but you also have information that needs a table presentation. Forms itself need a hierarchy tree so you can see a list of content and control appearance if controls are located on top of each other.

The options I have is to (1) use trees, (2) use pages and (3) use edit buttons where you pop into a specialized dialog. One of the pages I probably need is the event list and bindings for it – not sure – I actually plan an event selector as part of some diagrams, but every form and component are a source of events + how do I handle this before the diagrams are in place etc – I need to think about that one.

I am reaching a point where my illustrations regarding BSA are more and more the real thing. Property Editor is now real so I can start edit the components and add properties. I have a few days work setting up correct properties and then I will deal with saving and loading projects and a few other outstanding issues before I am on to generating code. Or well – don’t worry – I have plenty of work left yet.

Keep in mind that BSA uses Universal Diagrams, so unlike other design tools you can draw multiple things on the same diagram. In the illustration above I have drawn multiple dialogs. Each dialog has a Name, each component have an unique name within that dialog. Each dialog only cares about the component located on top of itself – so it is perfectly legal and beneficial to draw multiple dialogs on the same diagram as I have illustrated above.

Only basic components will be build in as the next, big feature is component libraries created by BSA itself. For example standard dialog boxes, gauges etc – I did decide to use a HMI solution fuled by GPU’s for a reason.

I used to design HMI solutions as a profession some 25 years ago, but never jumped on to the web thing. Watching over Web developers making HMI’s I was stunned about how limited their tools was as I have never understood why web developement needed to be worse than classic desktop development. Since the illustration above is a specification I can easily generate it as a Web page, desktop or tablet design at my chosing – without the developer needing to worry to much about the details except one – screen resolution if you use tablets/phones as target.

Qt will deal with execution on multiple platforms, but I do get an extra challenge using Qt – Print Preview and Printing is far from strate forward with that framework, but I will deal with that later.