BasicPI

One of the big things with any GUI/HMI is the capability to quickly create new user controls. The method I want to use is to let the user create this using a state-matrix. Layers in rows with layer 0=preview and columns as states. The control is illustrated above.

In this example I plan to rotate the needle on layer 2 to create a simple clock gauge. To do this I set in config that input value goes to layer 2 and on each state I connect that with rotation of the line. The final result will be a gauge that change background and needle color based on state.

I have some experience creating gauges in code and think  this will be a big time-saver + I can link cells to code if I need to and do other tricks. I am coding this as we speak so give me a few days and you will see it in action as we start adding user HMI libraries to BSA.

And there we area – still a bit work in progress with styling details, but I have passed the point of no return.

Back in the days then I coded MFC for User Interface I often upgraded my apps almost for free by just sticking to classic development. This was what I did here as well – I ignored dark theme assuming I would find a solution that could provide that for free. The solution is the 2nd on Nuget list – import a single style sheet, write a few lines of code and style up the places that needed manual styling – and voila.

I am ok working with light style, but dark theme is so much cooler and most important of all – I use colors and styles that get me into better moods. And yes – I need to change some of the above as this still is work in progress, but I am actually impressed over how fast and easy this actually was.

What I have done technically speaking is to avoid caring about colors and used a style sheet that override colcors and style for standard Windows components. I don’t fully understand all the XAML code yet, but I like the results and way of doing this as it means I can have different style sheets and completely change the look of BSA – but, that’s for later.

Work in progress. I found an example of how to change the style of Windows controls and voila – all the controls I have not styled myself changed. Notice the scroll bars etc. This is what I liked with Visual Studio back in the old days – you just stayed loyal to their scheme and suddenly get a lot of work for free. I need to update the rest of the color codes, but I can now go dark theme with close to no extra work. This is exactly what I hoped for as I decided not to dig into dark theme yet.

Also I discovered that the property folders I want actually exist – called “Expander” so I need to do less work than expected to build a property editor the excact way I want it. The Blend Style example that convinced me is seen below. This is basically a single xaml style file and a few lines of code added to you project. I was surpriced about how little extra code it was. For those interested you can find the original github code here https://github.com/DanPristupov/WpfExpressionBlendTheme.git under MIT license. Next time you see BSA will be in it’s final dark style. The all gray style used below is a bit booring in my eyes – I need a little bit more colours to light up the moods.

I don’t fully understand the styles.xaml yet and it is still a bit work in progress, but this was a very convinsing demo about how powerfully WPF/XAML actually is. I don’t pretend I like everything in it, but what I like is the sum speed of productivity you get – hours needed to make an advanced GUI solution. WPF is suprisingly fast to work. It’s been a few tweaks on the 2D engine, but I am very happy with the results and hours I needed to get there.

In comparison – I can (and am) doing the same in QML. I get the job done in Qt/QML as well, but working with QML is a steady stream of technical problems and an IDE that don’t do it’s job. The sum is that to do the same I use close to 5 x as much time. In WPF you write C# and XAML, but in QML you write C++, convert to Qt++, do QML bindings, write QML and JavaScript. It simply is a larger job to start with and add a poorly working IDE on top of that. That said – QML compares well to technologies we used 25 years ago like C++/MFC. And more important – QML and WPF is the only technologies I have seen that make using GPU’s decently easy. I have yet not tested the new MAUI, but I will.

The main reason I still work on QML is because I have auto-generated most of the difference and need a SDK that I can use to generate code for. While my primary target will be C# itself I also intend to pick up targets like QML. The result will be a huge difference in number of hours needed to code up systems – just stay tuned a few more months and BSA will be airborne.

Cost wise QML is a nightmare – Qt/QML with their designer cost ca 50,000.- NOK, while Visual Studio cost ca 5000.- NOK. And add to that the well of libraries like this one you find in Visual Studio. Just one advice – be very sceptical and think through what you import as you pick up nuget packages. Myself I only use MIT or similar licenses and source code unless I buy a commercial package. Make sure the library you pick up fits the bill.

Happy coding!

This list will increase, but I need to start with some basic components. The first version I need is HMI only together with a few other components:

This list will change and grow. The main challenge here is to limit the scope of this first release so I actually can release a first version. Also keep in mind that we are not just designing the screens here, we are actually coding the content as well. I have fetched HMI content from standard GUI designers, but it is important to remember that this is a design specification used to generate code. That gives us far more automation options. Using Modbus as an example – I want to grab a Modbus map as data source and be able to create a fancy desktop application in minutes and literally have the same on desktop and web without thinking about it – it needs to be that easy.

The easiest way to discuss properties is by discussing actual components, so I start with HMI Form. The terminology “Form” is well known for C# developers. I could have used dialog, window or whatever, but decided that “Form” is a good word. What you see below is the current HMI Form draft used in BSA. I will make this a bit more WYSIWYG later, but this is NOT the actual Form – this is the design of a Form. The actual Form will be generated from BSA. In this case I illustrate a Form that is a Display dialog containing a property list that design look and behavior. The result will be a long list of properties, but my experience with this from C# and other tools is that I 99% of the time only use a few selected properties – so lets start with those:

Colors and Style is something I set and later reuse. So the best idea is I think to remember what was last use and use that as a starting template. Simply said this is something I change once and seldom use so it can go into background on a separate page.

• Description is very nice to always have in front.
• Name of component
• Caption Enable and Title
• System Box enable
• Minimize, Normal and Maximize box.
• Starting Window state
• Window Size and Scale limitations.
• Window style – modal etc

The idea is to put the properties you actually use a lot and will change on a default front-page, while all the colors and nitty gritty details can go on specialized pages. The rationale for this is that I often spend time looking for things, so I want to see if I can make this a bit easier. The components will need a lot of properties so it makes sence focusing like this.

To do this one I will need the following completed:

• My mini dopcument editor.
• Standard single line text editor for name, title.
• Boolean to enable caption, boxes and features.
• Number editor
• Combo box.
• Color editor.

Form is a container for other components so it has no direct data-links.

The next task on BSA is to get my Property Editor functional. What you see above is an early demo draft to test a concept. I just wanted to get a feeling with how this could be done and test out the “Text Edit” part. The concept with a Property Editor is that you click on a component in a diagram and get properties for this displayed. Some of these properties are documents, source code and tables making them a bit complex to integrate without to many trade offs.

I considered using an existing Property Editor, but (1) WPF does not contain one, (2) this is a very important component for BSA and (3) it is actually straight forward to implement if your not afraid of huge work loads. It is a large job and you will get tired of me blogging about various editor details as this evolves, I will need a specialized editor for each datatype I use. Some are very straight forward, while others will need a good design and some fresh ideas.

It is three editors that are of special concern – Tables, Text documents and Source Code. These can all be implemented as a property line. Text document is illustrated above. This was far more capable than I first expected as I can widen the Property editor and get a larger doc. But, having all tables, docs an source code like this have it’s usage and limitations. I will need something more.

Having source code as part of the property editor is usefully as you want a quick look by selecting a block on a diagram that contain source code. You can see and even edit in the mini editor, but I thing we all agree that we can’t do more serious work here – we will need a proper source code editor. So the idea is to do both allowing Tables, text doc and Source code to expand into being a full View in BSA itself. This might also work for sub-diagrams. I obviously need to experiment a little around this and see how this works out. But, this is a functional area that will decide the success of BSA – it is that important. If I don’t get this to become something that is very convenient to use the entire tool will become a big, clumbsy failure. The reason is obvious – time usage.

This is the one thing you need to have in mind all time – time. BSA is  a productivity tool that should enable you to do more faster. But, I have used so many tools in my carrier that ended up as a failure that I am well aware of the danger of repeating that failure if you make the wrong choises or compromizes.

To move a line you select it. Selection is done by moving the mouse over the line and clicking the left button. As you select the line the end point markers will show and you move the mouse to an and point and simply move it with the mouse. If you move the marker outside the symbol and release the left mouse-button you delete the line. If you move the marker to a different symbol you establisk a new link with that symbol.

Lines in BSA are automated so you can chose line type, but you cannot change the line except for selecting position and connection of the end-points. This is done deliberately to avoid that you spend time on moving lines around. This is after all a programming tool, not a drawing tool. All links will behave like this, but some symbols will have more restricted connection options.  PLD Diagrams have a number of entry and exit paths that will show up as red or green connection points points. Red means they MUST be connected, Green means they can be left ‘as is’. In both cases you will need to connect the line to that exact connection point. I have done an earlier demo of this that I will use because if you use a diagram within a diagram you need to know what entry and exit points your connecting where. Just drawing a new link to a symbol would in theory create a new entry point – I did not get a good feeling about that one, but lets see.

The picture above show how a line is highlighted as you move the cursor over it. This is a GPU trick. The GPU will allow you to select the actual line, but hit test is very accurate and since the line is thin it becomes hard to select. So what I do is to create a helper line that is thicker to make selection easier. As mentioned only end-points can be moved on a link. I will at some point create an option to ,amually move corners as well, but I preffer automated lines to avoid that the developer use time fidling with lines. The rationale with this is experience with an earlier CASE tool where this was a big issue that used up a lot of time. You control lines by moving end-points and symbols, not by fiddling with line paths.