BasicPI

At one point I implemented a “document” – basically a tree with all the content in the diagrams and details about each object. You can see an example at left below. As the project grows, so does this tree and the full tree start to take time loading as this is based on a standard WPF component. This was an issue with Forms and MFC (Native C++) as well, so it is not just a WPF issue – loading big trees take time and if you need to maintain info in it the visual tree become a slug slowing down your app – or in this case it slows down BSA as we load and do operations that changes content in the tree. Solution ? In this case I just remove the tree because it was mostly a debug thing – the Dictionary is much lighter and have taken over anyway.

You might remember I wrote about performance issues earlier and this document tree was the cause of them. I accidentally updated the tree while loading making loading slow, and now I realize that any change causing this tree to be updated slow down operations – so for now I simply remove it – If I want it back I will need to implement partial load. This is a visual precentation so rather than loading the full tree I can loan only the visual parts. But, I don’t see the need for this after I implemented the visual Dictionary. And the worst is that I knew this because I have had this issue several times – the proper solution is called “partial load”. I have my custom Tree component used in Dictionary that support this. WPF is capable of handling very big trees very fast, but loading them is slow – so you load only the visual parts as you need them. DataGridView have an excellent callback for this.

The tree with HMI objects became a bit wide so i changed it to become a tree on several levels. It works by inserting a connection point and drawing inheritance lines from that, but this one will need some re-thinking because I ended up fiddling far to much with lines to get it look nice. At precent I am hammy I can do this at all, so I will just leave it on the list as low priority for now.

I changed the table editors to support inline editing. Added a checkbox to each row so users can select rows and execute delete, move Up, Move Down etc. Editing in the table directly is nice because the property editor becomes a bit messy if you expand to much in the tree.

Once we have a functional UML/ERD Tool it is vey easy to move on to HMI and automate creation of HMI as illustrated below. As you create large models it becomes a bit of work to maintain HMI associated with the model and this can easely be created and maintained automatically inside BSA. The result will be simple tables and edit dialogs, but those are still of great use as a starting point or in debugging.

Usually then I work on standard languages I use GIT or GitHub etc where you have an issue list associated with GIT. I want the same integrated into BSA so that I can automatically populate the list with errors as well as add manual entries. Such a list is very easy to make using WPF and as it is integrated into the tool it can link directly to places in code and be updated with the project. Once printing is done I will add this because I am in a phase where I start using BSA myself. This will not stop you from using tools like Github and in a future version we might even integrate directly to Github, Gitlab etc – lets see.

Just the color conversion + a few details left and I have achieved the first part to print diagrams. What you see below is the top of a preview. Color conversion is an issue because as we design on dark theam the colors might not be great for a white paper background. To deal with this I have decided to implement a conversion table of how to change colors rather than attempting some automatic scheme. I use selected colors in design and simply add their converted values in a table. In fact, that table is the light/dark conversion scheme. Some of you will recall that I started BSA on white theme and converted to dark – it is time to complete the process and to have a switchable dark/light theme.

In this example I loaded an existing diagram and intend to print it using the “Print Page” tool. PrintPage allows me to draw a rectangle on screen of what I want out as a page. I used this on an earlier CASE tool and it proved to be very valuable. The process of printing an entire diagram is the same.

The obvious next step is to cut out the selected area as a printable object. The procss is illustrated using 3D Paint below.

The last step is to position this on an actual page. Below you see what you can expect from a raw page – it is to wide for the A4 page (yellow) and positioned top left with no margins. Not the print we want and we now need to scale the print object, position it within the margins. To do this we compute print size and subtract margins as we scale.

The final page should by default look somethings like this assuming we selected A4 Horizontal (just an example) – Ignore the black background that will not be precent on the actual print.

It is a few more details to it, but the main concept is that (1) we need an automated way to print a page and control the content of that page if we are not happy with the entire diagram. This is what the “PrintPage” tool was created for. I will need to change the name “PrintPage” to soimething else, but you get the picture.

I use a Canvas as background for the diagrams and as I print I just provide a different Canvas using the same functions to draw on screen and paper. To zoom per page I just do the following – an example to zoom to 50%. The second part is to just draw the symbols using 100% position and size – the few lines below takes care of zooming.

Page page = new Page();
ScaleTransform scale = new ScaleTransform();
scale.ScaleX = 0.5;
scale.ScaleY = 0.5;
page.RenderTransform = scale;

It is a bit of manual work to use a XpsDocument and provide a print system and this might not be the only way, but all in all it is not a big job. What remains now is to calculate the size of the diagram versus size of paper and compute a zoom factor. After that I need to support margins and vertical/horizontal print pages as well as correct offsets so diagrams always start in the upper, let corner.

Next is to do the same for PDF and Web pages, but I suspect that I can reuse the XpsDocument for that. I also have yet to add the documents as I currently only print diagrams as is.

This shows 3 diagrams with circles being printed. I have only modified the Ellipse symbol to support printing so far and it works well with a few comments. (1) Colors on the symbol need a white paper version. (2) printing is 1:1 in size, I need to zoom and I have a path, but I want to investigate options. But, all in all – I am almost there. I expect to have a working first version today for paper printing. What you see in backgrund is page 3 displayed at bottom.

I am not so keen on the build-in Preview controls, but changing that is way down on my list – they work.

I managed to actually draw some objects on a preview page that I also can print. This is a good start and I will soon have the diagrams printed on paper.