In my first tutorial, I introduce the Composed Systems' open source framework called the MVA Framework. We looked at how to port a common UI application to the MVA style of programming. This tutorial picks up where I left off and covers how to have more than one UI in an application.
- By Chris Cilino, Composed Systems Partner
I recently became a partner at Composed Systems in July 2019. I hope you'll join me in my journey as I come up to speed on our tools set. One tool I want to highlight is the MVA Framework. The MVA Framework accelerates our development and give us flexibility to rapidly respond to changing requirements. And it can do the same for you since Composed Systems has made the framework open sourced.
I've found that I learn best when I first personally succeed at a task, and then share that knowledge with others. So I'm blogging about my journey to master the MVA Framework.
What am I doing here?
I gave a presentation at the 2019 European CLA summit titled “Applying a SOLID Framework for Cleaner Code”. The slides can be found on the Composed Systems website. I had a great time at the Summit and it was great to meet and talk about LabVIEW with the hundreds of CLAs who attended. I made a large open-source demo project for the presentation that I’d like to expand on and give more design detail.
I have been working on some pretty large applications lately that have highly dynamic behavior. Actors are getting launched and closed, views are frequently popping into subpanels--that kind of thing. At some point pretty far into my development, I started getting this dialog when my executable (EXE) shut down. It seemed harmless enough, until I realized it was not going away...ever.
I did the usual web snooping and stumbled on this LAVA post. Infinite Reset of Death sounds about right (IRoD, as I now call it).
If you haven't already heard--or tried it for yourself--LabVIEW 2017 offers a simple but powerful new language feature that definitely warrants a deeper look.
Somehow, I made it all the way to the CLA Summit in Austin--having used LabVIEW 2017 for months--before learning about this. Obviously I neglected to scan the LabVIEW 2017 Features and Changes list. At the very least, this new feature addresses the common tedium of making typed polymorphic APIs. It also potentially addresses a design problem I've been banging my head on for months. (A little more on that later.)
This will be a short post on a minor annoyance with putting together a dynamic UI in LabVIEW. I am currently building a multi-subpanel UI with Stream and my simple actor implementation and was annoyed with the difficulty of registering for events on the individual panes in my UI. This annoyance is rooted in the fact that I neglected to label my panes as they were created. So I wrote a very simple little tool for identifying and labeling populated panes.
I've been wanting to write a network extension for Stream for about a year now, adding the ability to extend the mediator to the network and allow pub/sub between actors on different machines. I finally got the motivation to do it after starting to collaborate with Jarobit Peña Saez at Bits 2 Byte on the Stream project. This extension is a result of our collaboration efforts and the sharing of ideas.
One of the many things I can stand to improve upon is how I version my software. I say this because throughout my career I have never adhered to a strict versioning scheme for the software I write. This has been tolerable because my decisions typically only impacted me or at worst my team, but now that I am diving into the world of open-sourced software I think it is time to embrace a standard for software versioning.
I love reading about ancient Roman history and I also love reading about software design. Occasionally those two areas of interest smash together in my brain and weird ideas come out. This post is one of those weird ideas, I'd like to introduce you to Janus, the god of software.