BasicPI

WPF have a very simple way of printing what they call a “Visual”, basically it print what you see on the screen, so to use this you need a UserControl. I loadet the diagram below and tested the PrintVisual statement.

I have a Brother DCP-9015 color laser that also has it’s own preview system and the result from “PrintVisual” on a diagram can be seen below. Basically it prints the screen as is and just drops the parts I did not request. I probably can  change that a bit and adjust background as well as scale it – not sure. But, I was happy to find that I hade a preview in the printer system to avoid too much paper usage as I test.

The more interesting function is “PrintDocument” that can print either a FixedDocument or a FlowDocument – actual tutorials and documentation on printing is a bit thin, so I will need to experiment a bit to learn the API. I want to start with paper printing because I like to make class diagrams and put them on the wall in front of me as I work. PrintVisual might just do the work if I can create copies in the background (not visual) and print them – we will see. The result is not exactly there yet, but this was a single line of code.

Documentation is a vital part of any project since we need to make presentations of our work on regular bases. Managers/Users who pay for your time will like to be kept informed and have a saying in what you do and this takes time, so lets attempt to automate it. Most engineers would love to just press a single button and have reporting/documentation done automatically. To do this we need to consider a few requirements for printing.

• Some developers will like to maintain documents/presentations manually, so to support those we need a capability to export diagrams and texts using standard copy & paste. They can then add these into their own documents through a clipboard.
• As I present diagrams I often go through PowerPoint and add some annotated content. We can do that in BSA directly and this will not require extra work due to the next point.
• Some users (like myself) would like to press a button and be done with doc/presentations by creating a PDF, print a doc or create web pages. And this is possible. Keep in mind that BSA already contain a very powerfully graphical editor that can act as a WYSIWYG page preview. The only thing we lack is (1) a capability to print a single diagram controlled, (2) a capability to include other diagrams within selected frames and the same with text. We can easily allow the user to create a document template that is populated as we generate/print the document – and most of the hard work is done already due to the graphics engine.

Displaying text is the easy one – we just extend our current text tool to display selected text from the repository on a diagram.

Displaying a sub-diagram should be more or less the same – we use a rectangle as base.

Setting page restrictions can be a variant of the existing Print Page tool.

Actually printing a diagram controlled will be some work – not sure as I will need to experiment a bit.

Adding a document template in Dictionary is straight forward.

As this will be a bit of work I like to leave the idea a bit while I consider alternatives and dig more into the details of printing. We also have the issue of including print support in user applications – which earlier was planned as a HMI Form.

Thanks for reading my Sunday ranting 🙂

It is quite easy to use a tree compont to add content and BSA itself to edit that content as a WYSIWYG document to create tailored reports that is automated according to a document specification. Later I generate an XPS document and print it – skip the Preview and use BSA Canvas directly. This is very similar to work I have done in the past where the user create a template of the doc that later is populated with requested content. I need to give this some thoughts…

A second concern is how we can add tools so we can add print/preview support to user applications as well.

Printing using WPF is rather straight forward,, but it requires a bit of work + in the case of BSA we need Print Control, Preview, Paper Printer, PDF Generator and Web Pages. In many modern companies they have a preference for PDF or Web pages rather than paper documents these days. I have done this before with C++/MFC and it was very easy + I just ran a sample test with WPF for FixedDocuent – the process seems to be that you print to a xps document and then stream that out – I will figure it out. The more difficult part will be to assemble BSA diagrams on pages to create an user controlled document. This task will probably take a bit of time to get right. In the old MFC you just created a PrintDC rather than CDC and drew the diagrams on that – I get the impression that WPF/XPS is similar.

It exist a few WPF examples created by Microsoft – this FixedDocument example (below) is one of them and seems to be perfect for Preview/Print on paper.  I will have to adapt to the XPS system, but that should be straight forward. I am thinking of maybe using a “content list” to include diagrams or print pages as we create the document. The use can this way control the content, but not all of the details and WYSIWYF parts. I think this is a workable solution. Another possible option is that I use BSA to create visual document pages and generate them in XPS – that also is straight forward, but one does not exclude the other. I can start with a simple, workable solution and build on that.

I am keen on releasing the first BSA version because the project has been on-going for some time + I want to scale up with more developers. The first target is to have a 1.0 with modelling only released before christmas.

My property editor is a key component, so I spend a lot of time looking for ideas on how to improve this. I am “OKich” using the old property editor where you have to expand every Attribute and edit a sub-list as illustrated below, but seeing the tables I also considered allowing inline editing in the tables.

So to improve this I enabled direct inline editing in the sub-tables. You still have to expand the attribute to edit some details, but it is much faster changing the key modelling content for classes and Data Tables now. This also includes Method Names and Event names etc.

I am as mentioned focusing on the modelling part because I have started using BSA active on a project myself. What remains now is printing/export of diagrams and maybe support for more UML alike diagrams. I have message sequence diagrams in mind as well as packages. The intention is to use Modules as packages allowing you to connect multiple modules in diagrams. As for message diagrams they are basically an alternative state-diagram showing sequence of messages in a communication dialogue. My previous experience with editing these is that it might be usefully to consider a combination of diagram and table-driven aproach – I need to think a bit on this.

As for other UML diagrams – It is nothing that stops us from implementing them, but some of the diagrams overlap a lot with PLD so it adds complexity to get code out on the other end. That said it is straight forward to implement the diagrams themselves. The graphical editor in BSA is very strong and easy to expand to just make dumb diagrams – so lets see what pops up.

I have a pragmatic aproach to modelling because the objective of BSA, PLD and PLAIN is to increase productivity on programming tasks. In real life you will be writing low level code manually ( or through PLD) – implement them as tools and abstract into a faster way of coding. BSA shall extend classic IDE’s, not replace them so you use the parts that works for you.

I think my next task should be to populate the table bar above. The first button is Add, the 2nd is Edit that is not needed because you can edit directly (IM style), then it is delete table row and Move Up/Down. As I have implemented inline edit it becomes more complicated to select a row or rows so I need to look into that details as well. I might need a checkbox at left of the ‘+’ button – not sure.

Another concern is the property tree example below:

This works well – I expand a list of methods and each of them have properties of their own and parameter tables that also have properties of their own. It all works very well, but the tree becomes a bit confusing with multiple rows and multiple tables/lists. I am not sure if I want to change this, but it is on my list of things to evaluate, One option is maybe to limit what you can expand at the same time now as we can edit tables inline – but again this can be done by the user, so I am not sure it is wise to add automation that might be annoying/limiting.

Happy coding 🙂

It exist a popular variant of UML called “SysML” (www.sysml.org) – it is close to UML2 with some variations – so why don’t we support it?

The answer is very simply that BSA support what it need to generate executable code and some of the modelling techniques are not practical in that perspective. We support UML Class diagrams with inheritance, associations and agregation – we also support ER-Diagrams as well as the concept of UML State Diagrams, but we have our own flow-chart/state diagrams more based on SDL (Specification and Description Language) simply because it gives a better coverage between functional descriptions and application logic.

Anyone who have used state diagrams know that you can’t just have states and transitions – you also need logic mixed in – if you don’t you end up with diagrams that are far away from the executable logic and less readable. So yes, we do support UML, but at our own terms because we target actual code.

Another big difference between UML/UML2 and BSA is readability of executable logic. Since BSA is a programming tool we start with diagrams and end up with code. We need to give the user an easy way to see and debug executable logic – this affect the diagrams as we on lowest levels need to visualize far more that high level details. A simple state-diagram is shown below.

As I create tools in BSA I also use a part of BSA to create that tool. The current version is illustrated below  it is a table driven application where I specify the tool, it details and properties, As I generate code I get Load/Save end editing generated – while I need to draw the symbols in manual code. As I move forward I will modify this to be included in BSA as a Tool Manager to create user tools. User tools will then appear in the Tool or Dictionary folder. I think the key concept need to be that we have a list of static-build in tools to create a base reference we build on. But, the concept will be that you can create your own libraries and add them to BSA. The tool itself is a specification – the actual code can be external libraries or code created by BSA. Tool behavior inside diagrams is the same as build-in tools – all the same mechanisms/rules will be available.

I decided to do Precentation the easy way. I simply add a “PrecentationOf” attribute that by default is blank. The Dictionary can track multiple items with the same name, so we just add a note to classes that are a precentation of something else. And then we just use the existing property to create a virtual class. BSA will expect that one version exist with a blank precentation field. As of now this is manual, but I can add more automation later.

It is UMLClass, Data Table and ModbusTable that will need this capability to visualize snips of the original table. This was a simple solution, but I think it will work well. I can also add a filter on the Dictionary to not list precented objects or simply list as sub-list of the original. This also means that I need a diagram with the original class for now – will look into creating some objects directly in the Dictionary later.

As we use the objects for Coding the compiler will see that this is a precented object and look for the original. The compiler will also check that we only have one original object of each name, but nothing will prevent the user from entering free names during design.

BSA has been something I have worked on on/off for the last 3+ years, but some of the concepts has been in my head for close to 40 years. This is not the first CASE tool I build or work with. This first release will target object and data modelling – UML class and ER Diagrams simply because I need these parts for my own work. Currently I want to complete the dictionary and the precentation issues because this is the reason I can’t use other modelling tools – they either cost to much or is less usable on some of the more important concepts in modelling,

Step 1 – Data modelling

Step 2 – Code Generator/Compiler

Step 3 – HMI

Step 4 – PLD

PLD will be the hardest part to complete as it is a lot of details that will need a bit of try and fail. On Data Modelling, HMI and Code Generation I have experience from other CASE tools, but PLD is very new and non-tested concept. Everyone knows it is possible to code with graphical tools, but many also know that this way of coding tend to be slow and limited. Rather than increase coding speed you end up decreasing it because of limitations in the tool – this is why PLD will take some time to get right. That said the combined power of data modelling and HMI is a alone a big win in BSA.

Stay tuned and thanks for the patience with my english skills 🙂