BasicPI

Many modern applications use custom theme/styles, but this is actually far more difficult to implement than you would expect on Windows. Windows have a lot of standard GUI components where you can control most, but not all colors and styles. So, if you want dark theme you either need to buy a library or start making custom components that actually control all colors and styles. I decided to do the later. And while at it I also add new super components to make life easier. My objective is a dark theme not so unlike the one used in Visual Studio itself. I decided to code desktop apps in C# simply because Forms have improved their graphics and C# Forms is easy to work with.

This simple app is my component scratchpad showing some of the components I have made so far. You see small buttons, scroll bars, labels and edit fields. On bottom right you see a classic Windows combo box and as you can see I can’t control border colors yet. Looking at the edit controls (top right) I almost got it right using a standard component, but I could not control the border color. What I did was to use a edit component without a border inside a custom control where I override BorderStyle. I am realy pleased with this one because an edit text component is a bit of work.

The next control I had to work on was the tab strip. I have to modify the close cross a bit, but again it is a custom control with a small button and custom label component. As you can see I still have to do the menu and windows title fields on top – in fact I want to move the menu into the caption bar just like in Visual Studio to save space.

This is the beginning of my own Object Editor. I tried hard to avoid having to make this, but at the end I decided to jump into it. First of all this is a complex component as it is a simple grid with in-line editors and at the end it simply was to much that I could not control. But, having made the basic components properly it is easy to re-use them in a grid like this. I have not coded attributes properly so it just use reflection to grab a few edit fields for show yet.

This is a lot of work, but it is also fun. I want a proper HMI on my systems and I have made so much electronics that it is due time I start on the top-side part. C# also support Linux, Android and OSX. I actually ported a Forms application to Ubuntu once with just some minor changes. It will be a bit more work to port this HMI framework, but one step at the time. At this time I want to get the designer working and C# is the fastest way forward.

UML is a well accepted standard for modeling complex software solutions, but it has never reached executable accuracy. The standard lack a technique that allow executable logic, which is exactly what PLD does. This is key to having a tool with 1:1 between diagrams and code.

I started modeling with Entity-Relationship Diagrams years ago, and these diagrams still have great value on physical database designs. ER diagrams are also a sub-set of class diagrams on the front-end, so they are easy to include.

HMI design is crucial if you deal with HMI. Starting this designer task I wanted dark-theme, and that means I have to take control of every HMI component to control colors anyway. Creating an HMI designer is on the front-end only about drawing symbols on the screen – far easier that the complex diagrams with rules.

Putting an ER designer and HMI designer together is alone a powerfully tool as you create database applications in seconds. This is what classic CASE tools used to focus on. Having this capability is nice, but only a side-effect of what I want.

PLD is a new technique combining two very popular techniques. Classic flow charts to express executable logic has been here since the beginning. SDL (Specification and Description Language) is still heavy used in telecom. PLD build on these two for graphical language and extend with techniques to have an executable specification. A diagram that in a few second describe what the logic is.

UML State Diagrams sneaked in because I liked the concept and it fills a gap between PLD and System Diagrams. PLD can be used for system diagrams, but state diagrams are more efficient.

As we also work in object oriented languages a class diagram is a must. This looks like an extension of a ER Diagram, but while a ER Diagram represent physical tables in a database (the actual container) a class diagram represent a definition of an object that needs to be declared – it is an advanced datatype. I use class diagrams heavy as I code in C++ and C#.

At the end we want to press a button and generate code. The concept is that you draw diagrams, press a button and your up running. But, it is good reasons why attempts on achieving this has failed in the past – lets see if it actually work this time!

UML State Diagram is a standard, but I find it’s implementation into tools to be wage. So, I implement my own adaption because I intend to have a 1:1 with actual source code. This is not uncommon as most automation tools will have to make adaption in areas where executable accuracy is weak.

I was introduced to programming with UML State Diagrams through a different tool that I found to be of little use. But, it demonstrated the concept and I often use state diagrams so why not have one that actually is 1:1 with code on high level. A state diagram lack a lot of executable accuracy as it is only a high level diagram, but it does have some excellent qualities of showing event/signal driven flow on high level and as such accelerate overview of source code. The examples below are preliminary from an experimental tool.

The first symbol I use is the Entry point – a simple circle with a single output connection point (the red dot). All events inthese examples have the name “Hello”. The Red dot indicate that this diagram is illegal as a mandatory event is not connected.

This adds the Exit symbol and an event-flow between them showing a minimum, legal diagram. To draw this you first select the Entry/Exit symbols adding them, secondly you select Event Flow and draw a line between the 2 red dots. The dots dissapear as the events are connected. An output must connect to an Input etc.

The next is the State symbol itself. As you select a state you can chose between a generic sub-diagram, block of C++ code or premade component. All state’s will have a list of input and output events that at start will be displayed as Red or Green dots. Red dots represent abstract events that must be connected, while green dots represent virtual events that you can chose not to implement. Virtial events can also be hidden (tagged as ignored).

The dots will be replaced with lines and normal text as events are connected. The text “This is an example body..” will reflect the actual content – or by your choise a free text. The standard actually have a entry/exit notation – and I will need to do some adaptions on that.

This is a Fork where an event is duplicated and sent in parallell to two different states.

The opposite of a Fork is a Join that syncronize events.

As mentioned – this is an experiment, so I need to adapt as I go to develop the tool. The technique is not as mature as PLD and I am not sure about it’s actual worth, but I like the concept and want to see if this way of coding actually add value then done right and in combination with other techniques.

The tool itself needs a bit of work before its usable for anything and its an experiment as I complete the graphical editor that will be used for PLD as well.

Just showing a test diagram on the UML State Engine Designer I am making. It is stoll lots of work and details left, but progress is actually going fast the days I work on it. As for now this is just an experiment. A state engine can visualize some top level flow, but the details of the logic get hidden. My plan is however to let users chose between sub-state diagrams or code editors and see if that works out. It is regardless a cool tool even now.

The red dots are pre-defined events – input on left and output on right. Red means they need to be connected. As they are connected the red dot disapear and is replaced with the connection line. One trick on a diagram like this is to automate lines to avoid that users spend time making lines look nice.

Keep in mind that this is an automation tool that will generate source code, it is not a drawing tool. That said precentation of readable diagrams into doc is one of the objectives.

Interaction with source code and/or PLD is straight forward. PLD is excellent for visualizing logic and will handshake well wil State Diagrams.