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 (couldn’t 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 weren’t 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, Michael’s 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 Lacasse’s 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 Pattern’s description of MVC. These slides attempt to draw parallels between HFDP’s 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