0

CLA Summit Splash Screen, Loading

National Instruments
LabVIEW (and LV R&D)
Certified LabVIEW Architects (you make this event great)
CLA Summit co-chairs (couldnt do it without you)
High quality technical presentations (teach me master)
1
2
Most italicized text was added after the presentation was given at the CLA Summit to
reflect audience responses.
3
Hey NI, how safe is VI Server?
4
As new devices are supported, and the user interface experience adapts over the years
with styluses, touch screens, multi-touch screens, the ribbon, changes in screen size;
you want to be able to modify the user interface portion of the application without
modifying the core application.
5
6
7
8
9
10
11
12
13
SubVIs were created in LV1, but control references werent added till LV4!
14
Control references add tremendous flexibility to applications, but because it imposes no
encapsulation or rules of engagement and allows each subVI to have complete access to
each control, it actually contributes to the problem of coupling.

To be clear, using control references in subVIs is fine as long as the purpose of the subVI
is specific to managing the UI, as opposed to a subVI used in the solution of the business
problem. Furthermore, complex parameters (clusters, objects) passed to business
solution subVIs should not include control references, but instead should only operate
on the state and data of the business solution, and communicate the result back to the
user interface module, not the UI itself.

Dynamic discovery of control references is antipattern because it requires hardcoding VI
names and control names.
15
16
Several people at the summit indicated they have used Xcontrols extensively to simplify
the interface between UI and implementation, and even constitute the majority of their
UIs.
17
Many people at the summit shared that subpanels have become their defacto way for
decomposing their application UIs.
18
Imagine how painful it would be to programmatically display the correct string for every
string indicator, label, and caption.
19
Limited use case for value-only use, no access to properties or limited post processing.
20
21
If your application has a fairly homogeneous user interface, such that content and format
of that UI can be easily represented in a database, the user interface then becomes a
very light weight part of the application and can be more easily abstracted from the
business logic. In fact, Michaels presentation, the application that executes the business
logic is executed in a separate ActiveX EXE.
22
23
24
I once wrote a flexible test application in C++ that interfaced with a variety of IO
including relays, POTs, DIO, AIO, and more. Using the GUI they could configure the test
application to resemble their test fixture; create the controls and indicators that made
sense for their needs, and arrange them in a logical layout.

This could be done in LabVIEW either using dynapanels, or by creating a worst case
number of controls and indicators for each type and only showing the controls needed,
but both of these seem like work-arounds rather than the right solution.

There were a number of attendees that indicated they too were implementing solutions
similar to the Veristand and/or Wireless GUI techniques, and there was a surprising large
response (20%?) to the question about wanting the ability to programmatically create
controls/indicators.
25
Any time you can separate the business logic domain from the UI domain, you
automatically achieve separation of UI from implementation. Granted, this also incurs a
number of disadvantages, such as increased required skill set and increased complexity.
Staying in a single language has its advantages, if that language has strong
support/feature set in the targett hardware/software platform.
26
27
Avoid the temptation to put control references into the class(es) implementing the
business logic. Doing so might allow you to reuse this class with different LabVIEW UIs,
but would not be conducive to being used with a UI written in a different domain.
28
29
30
Michael Lacasses later presentation made an excellent distinction between a design
pattern and a frame work. Design Patterns imply a specific implementation model,
where as a framework is more like a concept that is open to interpretation. In fact, the
CLA Summit consisted of numerous presentations and conversations of different flavors
of MVC. What I have presented here comes from Head First Design Patterns description
of MVC. These slides attempt to draw parallels between HFDPs by reference
implementation and how this can be described/implemented in a by value messaging
architecture.
31
32
Using composition, an object can, at runtime, substitute any object to utilize a desired
algorithm as long as it follows the same interface. The client is unaware of these
changes.
33
34
35
The Active Object pattern may also be appropriate for the first bullet.
36
Sorry to scan this directly out of the book, but I think this diagram makes the interaction
between the M, V, and C very clear.
1. User performs action on View, View calls appropriate method on Controller to take
action.
2. Controller calls method(s) on Model to act on that action,
3. Controller also calls methods on View to update UI.
4. Model responds to action and notifies registered observers that it has changed state.
5. Registered observers can then call methods on the model to retrieve state
information, not set it.

Consider replacing View with Front Panel example, Control and Model with block
diagrams.
37
38
39
40
41