PaulL

A client (the Context) calls one or more methods on an interface State class -- this is an implementation of a Signal trigger. We can also have a trigger based on an internal evaluation of some variable (Change trigger). Each trigger may result in a response: this could be a state transition, which itself may one or more effects, or it may trigger an update on an ongoing activity. The implementations inside the various state classes in the hierarchy determine what happens for that state. Yes, they can and frequently do call their parent methods so that common behaviors do not need to

This is the State Pattern, not my idea. (There is a link to my full presentation in this thread https://lavag.org/topic/17937-state-machine/#comment-107773.) Your inclination is correct, in that the States are usually flyweight objects. (This is the case in our implementation.) The hierarchical relationship allows for override and extension, so that each state has only the code it needs. This facilitates a clear and robust implementation of a true state machine, without repeating behaviors. For instance EnabledState in our implementation processes an error trigger for it and all its substa

The attached file extracts the relevant slides from a presentation I made at NI Week presentation 2012 that presents just such a case. (I left the slide on Transition Execution Sequence at the beginning of this selection because of the reference.) The hierarchy can be determined at compile time and stored (not so robust), or at run-time using a couple somewhat complex approaches (adding code to the classes to derive the hierarchy, or attempting casting and see if it fails). Reflection would provide a solution, I think. (The hierarchy could still be determined once at the beginning of prog

There is the following statement in the KB (Blurry Icon Editor Linux Machine): "This will change the fonts for all of the text within your LabVIEW VIs and you will only be able to use the default font with this configuration token in place." If UseXftFonts=False in the labview.config file, we cannot even change the size of the font. The font size is too large to use in the icon editor. If I set UseXftFonts=True in the labview.config file, I can once again change the size of the (blurry) font. At the moment, once I exit the icon editor, the text on the final icon is not as blurr

That is super helpful! I'm not sure how my search didn't find that. I tried it and it works with the LabVIEW Application font. I have to figure out how to get back to Small Fonts since once I selected something else it is no longer in the list. Many thanks!

In addition to the Small Fonts, we have tried the LabVIEW Application font and the other similar fonts (System font, etc.), and many of the other fonts that appear in the list. None of these worked. What do other people working on Linux use?

Out of the box text in the icon editor looks awful. (See attached image, which is better looking than most.) (Yes, even with small fonts: https://forums.ni.com/t5/Linux-Users/Labview-Icons-under-GNOME/gpm-p/3379530.) Details: LabVIEW 2016 64-bit, CentOS 7 Linux OS We have tried many things to get this to work, to no avail. Does anyone have a solution?

When we first deployed object-oriented applications (using by-value objects) on RT targets (quite a few years ago now) we encountered long build times (10 or 15 minutes) that were not repeatable (repeated deployment using the same build specification was successful only a small fraction of the time). This situation was unworkable. We learned that the problems we encountered were due to the tangle of relationships between elements (Rolf's "similar stuff" above). Consequently, we implemented interfaces in the manner I have described elsewhere to reduce interdependencies between elements. Builds

I contacted NI Support about this. NI Support created a related post on the Idea Exchange: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Unit-Test-Framework-Support-on-LabVIEW-for-Linux/idc-p/3801989#M38826. If this interests you, please consider adding a comment or a vote.

Nothing. So do we conclude no LabVIEW for Linux customers are doing unit testing, then?

So, what choices, realistically, do we have for writing unit tests for LabVIEW for Linux? https://forums.ni.com/t5/Unit-Testing-Group/Unit-Testing-tools-in-Linux/gpm-p/3396916 (In 2014 NI was going to evaluate the level of effort to make the UTF available on Linux.) https://github.com/JKISoftware/JKI-VI-Tester/wiki (May be available in the next release). https://github.com/JKISoftware/Caraya (I guess this might be available on Linux?) Are there any other known options? In our case we need to support integration with Jenkins. I don't think that will be the problem.

My recent experience has been managing software engineering teams building complex systems of components (especially large telescopes). In addition to LabVIEW, I have tremendous expertise in modeling (SysML and UML), design patterns. systems engineering, and project management. You may have read some of my papers on LAVA! I can help your organization build complex, robust systems quickly! res Jul 2017 without address.docx

Join us in constructing the Large Synoptic Survey Telescope (http://lsst.org/). We are looking for a talented LSST Software Engineer: https://rn11.ultipro.com/spa1004B/JobBoard/JobDetails.aspx?__ID=*AB6A19BE44FB88D0. Requisition Number 15-0182 Post Date 9/21/2015 Title Software Engineer City Tucson State AZ Description The Association of Universities for Research in Astronomy, Inc. (AURA) operates several observatory centers (including the National Optical Astronomy Observatory, the National Solar Observatory, Large Synoptic Survey Telescope (LSST) and the Gemini Observatory) in

You are correct. The particular implementation of the Factory Method Pattern I show here does include references for all available objects. This is because: 1) Most of the factories my teams build are for applications that actually use all the object types available. (This is certainly true for the State Pattern and Command Pattern, not necessarily true for the Strategy Pattern.) (Of course, I only include the objects that are relevant for the specific application.) 2) We want to maximize performance, so we want the state objects to be in memory. (Again, this is typically more important

Fair enough. My perspective is that we need to equip a broader range of developers with an understanding of interfaces, etc., so that they can use project libraries effectively. Look, I think the loading-of-dependencies approach is consistent (the loading of parent libraries, maybe less so) with LabVIEW's overall linking model, and I think there would be trade-offs if LabVIEW were to depart from that model. I think it is straightforward to work with that model, in such a way that project libraries are helpful (in certain circumstances), especially when coupled with interfaces, so I don't th