BasicPI

The purpose of a design grid is to force symbols to align to a grid line at left, top, right and bottom so they are easy to position and size compared to eachother. This speeds up drawing/design as you use less time sizing and positioning symbols on the screen. The default design grid is 10 points which is fine for diagrams, but not for HMI.

The picture above show the issue with a grid of 10 pts – the space between fields become very large – for some apps this will be ok, but for many apps we want less space. I have two solutions to this (1) is to adjust the field margins on top/bottom – in the above example I have adjusted the top to demonstrate – If I do top and bottom on every component – basically add a standard Margin I can put them edge to edge and they will still look like separate fields. This is one of the usages for the property Margins that specify offset left, top, right and bottom. (2) I can switch to a smaller grid of 5 points. The easy way of doing this is by having two separate grid buttons in the menu – one for 5 and 10. Actual grid size can be set by user, but 5 for HMI and 10 for diagrams are good values. The same goes for default Margins (that can be overrided).

The same screen layout with 5 pixel grid can be seen below – we use far less space:

Using less space can also be done with margins. Doing diagram alignment on 5 pixels is however a bit more fiddly than with 10 pixels which is why I want both of them.

This last one uses Margins, but I do now get an issue with the height of my edit box compared to font I use. This was with 2 pixel margins top and bottom. The next picture is the same with 1 pixel margins just for demonstration. But, even this will cut some characters at bottom so with a fontsize of 12 I believe 20 pixel height is optional. If you really want to use margins like this you need to downsize font as well.

The good thing about these details is that an user should never be forced to think about them at all – it will be cases where you sit an fiddle with visual details, but the objective is to have an automated path that is straight forward and sufficient for 99% usage cases – simply yet another issue I don’t want to spend time on once BSA is up running. You can set grid sizes, turn off grid or set default margins to have your own automated path.

This show a classic label and an associated edit field. Notice that the text “label” and “Text” are not aligned. In my case I force the controls to align to the grid and in this case I get the side effect that these two texts do not align. One solution would be to switch off the grid, adjust the label and switch the grid back on – thay would work, but it would also require us to do this on every label and checkbox etc. So what I am about to do is to add a property called “Text Alignment” and make sure that these align to the same with the grid switched on. All Windows controls contains a property called “VerticalAlignment”, but it don’t work in a consistent way between controls.

This is one of the reasons I use a grid – to make it easy to align controls in size and position and it needs to work straight out of the box so we don’t use extra time on these details. My challenge is however that I will need to force  all Windows components I use. The picture below demonstrate why.

Notice that label and checkbox text are aligned on top, while edit field and combobox text are aligned center. This just look unprofessional and is a detail that will annoy everyone if it is not fixed. This is also a common issue in some GUI designers as it is not the first time I observe the need to sit and adjust this manually. My challenge is that I will need to fix this in my own HMI designer, but also in every target platform SDK.

The easy solution is to just offset label 3 points from top to compensate for the fact that grid space is 20 and font size is less. I would expect VerticalAlignment to do this, but the ressults using that property vary from control to control.

The adjusted result can be seen above – the actual top adjustment needs to be calculated based on font size used. In the final code generated we just add Y + YOffset and the result should be fine. This is basically an adjustment I have been doing manually in every GUI tool I have used – it is usually “solved” with a smalle grid, but using a 10 point grid means things align easy in position and in this case I automate the adjustment that I otherwise would be sitting doing manually.

I just copied text from an earlier blog into my mini text editor for demonstration –  and this works out very nicely. The capability to edit text is usually a dinosourus in these apps, so I am very happy to see that this one actually works out well and are very functional. I need to code up tools to get rich text and images, but I could actually do with this alone. This one is a big win, so I am considering ditching the full view editor – not needed,

Engineering is a lot of try and fail, so it is very nice that some ideas actually work out as planned because I have plenty of those who don’t.

Many of the HMI controls use actual Windows Controls as base. In the example above I draw a simulated design form as a symbol and use various build-in controls to get the result as real as possible. The challenge is that these controls are designed to be in control – not be controlled by a designer – so getting them styled correctly and to behave inside the designer actually is a bit of work.

At the end of the day I probably will need to create a SDK with my own controls for each platform I support. I will look more into that as I start generating source code from BSA.

Looking at the edit fields you also see that the corners are not drawn as a complete line – this is the control and a detail I seem to lack control over.

Another issue is the color of the check box – I can control text color, but not the check box itself etc. This is very classic Windows Build In Controls – that said – I did discover styling capabilities capable of changing more than I believed I could, so might be  afew tricks I need to learn – but, I still think a lot of custom controls will be needed to add features.

Just to prove my point with borders being to dark I encreased them from 0x32,0x32,0x32 to 0x64 and it makes a big difference as you now actually can see the outline of the control. Keep in mind that these border lines are design help, not actual borders on the real Form. In design mode we are more interested in design parameters than exact look & feel – that said it is nice if it is close.

The HMI Designer part is progressing, but I must admit that it is a large project and I don’t always have time to work on it. Finally started to wrap up the Property Editor and styling up HMI controls that still have light style. The example form above got a bit dark and close to the background so I need to visualize the borders a little more.

Upgraded the project to Visual Studio 2022 and intend to make a test port to Avalonia later. Avalonia is WPF for Windows, Linux and Mac with iOS and Android coming. This is open source with MIT license and contain a few components that interest me.

I have complained about QML making design over-complicated in the past, but I must admit WPF also has it’s tweaks. That said I have never regretted moving from QML to WPF – C# integration into Visual Studio makes it worth it and I am exited to learn about what Avalonia can do – later.

This first version will be able to design HMI with a datasource and read/write data from/to that, but it will not be able to do much intelligent processing before we add PLD and the rest. It will however generate code we can continue on. My first datasources will be Modbus, CANbus and some database – I will probably wrap up a SQLite module, and maybe MySQL – lets see.

I recently bought myself a 14″ Asus VivoBook – great laptop for the price. I only have the standard laptop mouse and a single screen on this – which is a reminder that I will need to adapt the user interface for a more – keyboard only – option later. The current interface is dpending on mouse and 3rd mouse wheel which is not that available on a laptop only. Myself I prefer a desktop with 2 screens as a minimum then I work, but the laptop enable me to work more from my living room.

Looking at the example above I typically have five events I need to process:

• Starting the dialog
• Updating the dialog  with data from a datasource
• Three button events.

In reality there will be more, but lets keep it simple – the challenge with a HMI only designer is how do I process those events? I have two options (1) I can generate code where the user add the missing part, or (2) I can add in a minimum of UML State Diagrams, meaning that a HMI only design will have little purpose except for being a milestone. I need to think about this one a little. I do however have a secret agenda because I work on QML from time to time and Qt’s HMI design tend to crash + I want to autogenerate a lot of the code to speed development up. This is why Qt/QML is on my target list.

Don’t take me wrong on QML – WPF/QML is the only two technologies I have found worth working with. QML is very capable and some parts are better than WPF, but I stick to WPF because it is much faster and more productive to work with – that said – my next system will be made in BSA.