JKSH

This article does a good job at narrating the author's journey from being an OOP enthusiast to an FP advocate, and helps us understand his feelings and frustrations. However, it does a poor job at illustrating OOP's actual shortcomings/pitfalls. Let's have a closer look at the author's arguments. Inheritance: The Banana Monkey Jungle Problem This is a strange example. It's like an OpenG author who decides to reuse some OpenG code (say, Cluster to Array of VData__ogtk.vi) by copying the VI into his project folder, and then is gobsmacked to discover that he needs to copy its subVIs and their subVIs too. This shouldn't be so surprising, should it…? Anyway, it sounds like his main gripe here is with excessive dependencies (which is influenced by code design too, not just the paradigm), yet his stated solution to this problem is "Contain and Delegate" (a.k.a. composition). Sure, that eliminates the class inheritance hierarchy, but I don't see how that helps reduce dependencies. It feels like he's trying to shoehorn the "You need composition!" message into every problem he listed, just so that he can argue later that inheritance is flawed. Inheritance: The Diamond Problem Yes, this is a real issue that can trip up the unwary. However, the author claims that the only viable way to model a diamond relationship is to do away with inheritance ("You need composition!"). He disingenuously ignores the numerous inheritance-friendly solutions that can be found in various languages. Inheritance: The Fragile Base Class Problem Yes, this is a real pitfall. This is his most solid point against inheritance. Inheritance: The Hierarchy Problem His main point here is, and I quote, "If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere. What you won’t find is Categorical Hierarchies…. [which have] no real-world analogy". I'd like to hear from someone who has implemented a HAL (or someone who's a taxonomist). Would you agree or disagree with the author's claim? Encapsulation: The Reference Problem This is another bizarre example. His logic is akin to, "An LVClass lets you have a DVR as a data member, and it lets you initialize this member by passing an externally-created DVR into its initialization VI. Therefore, an external party can modify LVClass members without using an LVClass method. Therefore, LVClasses don't support encapsulation. Furthermore, attempting to prevent external modification is inefficient (and perhaps impossible). Therefore, the whole concept of encapsulation in OOP is unviable." This is a huge stretch, IMHO. Polymorphism His main point here is, "You don't need OOP to use polymorphism". This is true, but is not a shortcoming. Also, the author paints a picture of interfaces-vs-inheritance. They are not mutually exclusive; they can be complementary as they serve different use cases.

A-ha. How very sneaky. I wonder if this is a bug such that the dialog is supposed to say"The feature you just selected is only available in VIPM Pro Edition. Please choose from the following options" instead of "Error"... Anyway, this wasn't what I hoped to hear, but at least the cause is confirmed now. Thanks for testing this for me, @LogMAN!

This is an offshoot of https://lavag.org/topic/19414-can-i-save-as-a-vipb-file-in-vipm-and-keep-the-old-palette-if-i-change-the-source-directory/. That thread discusses hand-modifying the XML data in a *.vipb file, which Jim Kring himself seems to accept as a viable solution in some cases. However, when I try that, VIPM says, "VI Package Builder was unable to open the build spec due to an error." I initially thought this was new behaviour introduced in VIPM 2016, but downgrading to VIPM 2014 SP2 didn't change anything. I'm now unable to downgrade any further, as my PC is convinced that 2014 SP2 is still installed (even though it's not...) Could someone kindly try the attached *.vipb file and see if it opens? It's a bare minimum default file, with only a description summary added. I've hand-modified the summary from "Lorem ipsum" to "Larem ipsum" and now VIPM refuses to open it. Thanks! Dummy.vipb

This sounds like either a bug or a poor design decision. Have you raised this with NI?

Darn, I just remembered why I had the *.vipb in the root folder in the first place: I wanted the Source folder to contain my library's API and implementation only, but the Examples are neither so I put them in a separate folder. Unfortunately, VIPM doesn't let us include things in the package if they're outside the Source Directory (which means I now can't have examples in my package). I'll downgrade VIPM to see if I can easily modify the *.vipb's XML data after the palette is auto-generated. If not, I guess I'll just have to move my Examples folder... (If you can think of a nicer idea, I'm all ears!)

D'oh! So simple. Yep, that did the trick. Thanks! (I miss the old "Mark as solution" feature from the previous forum)

Good idea, thanks. So I made sure my LabVIEW code remained unchanged, and I altered 1 character in Basic >> Display Information >> Product Description Summary (from 'o' to 'a'), then re-saved. The following items changed in the *.vipb file: The "Modified_Date" attribute in the top-level "VI_Package_Builder_Settings" tag The "ID" attribute in the top-level "VI_Package_Builder_Settings" tag Every single "GUID" value under the "Functions_Palette_Data" tags. I'm pretty sure these fields existed in the previous version of VIPM too.., but perhaps they've been given a new role. (If so, why???) I mainly use Notepad++ too I know it's definitely not a problem of mis-encoding, because: I used a hex editor (HxD) to alter exactly 1 byte in my Product Description Summary text (from 'a'==0x61 to 'o'==0x6F). That triggered the same error message. I then used the hex editor to change that byte back from 'o' to 'a'. That removed the error message. Perhaps I should uninstall the latest version and go back to the previous...

Hi Jim, I just tried editing the XML on a VIPB file, but VIPM 2016 complained, "VI Package Builder was unable to open the build spec due to an error." Even changing a single letter in the product summary/description triggers this. Has some kind of checksum system been implemented in VIPM 2016? Is there a way to continue making manual edits on VIPB files? Thanks!

I have a project structure like this: <ProjectRoot> (Project.vipb) Examples Example1 Example2 Source Cpp LabVIEW LVClass1 (Method1.vi) LVClass2 (Method2.vi) The auto-generated Functions Palette is structured like this: [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass1 >> Method1.vi [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass2 >> Method2.vi However, I would like a simplified palette structure like this: [Functions] >> [Company] >> [Project] >> LVClass1 >> Method1.vi [Functions] >> [Company] >> [Project] >> LVClass2 >> Method2.vi Is there a way to get VIPM to auto-generate the palette that way? I can think of a few workarounds (restructure my project, or add every palette folder manually) but I'm hoping I don't have to resort to them. P.S. Sorry if this is the wrong place to post this, but I'm unable to post on the JKI forums

If you want to make every child of Class B a friend of Class A, that means that A needs to know about every child of B. If you ever need to handle a new status byte, that means you need to create a new child of B, and you also need to update A (to add the new class to its friend list). That's definitely not ideal. However, if you make only Class B a friend of Class A (such that the child classes don't call A's non-public methods directly), I think it's fine. Some more details about your system would be helpful for identifying the "best" design. However, here are some thoughts: Do you truly need one child class per status byte? Would you consider putting one big case structure in HandleStatusByte.vi, that uses the byte as the selector? Do you truly need a separate class to handle the status bytes? Would you consider letting Class A do it directly? (I presume Class A is the interface between your controller and the hardware; all commands are sent through Class A and all status bytes are received through Class A)

There's a few good reasons to separate compiled code from VIs. Now, the option is also available for custom controls/type definitions. I'm wondering if there's any benefit whatsoever in separating compiled code from these? None of the reasons for separation apply to *.ctl files, after all. In fact, it might even be slightly detrimental -- in a few quick experiments, separating compiled code increased the size of the *.ctl files! (Cross-posted at http://forums.ni.com/t5/LabVIEW/Should-I-quot-Separate-compiled-code-from-source-file-quot-for/td-p/3318096 )

You could also write and run a VI that outputs 0 V Alternatively, switch off the cRIO and turn it on again.

Hi, You need to do two things: Make sure you shut down your program properly... not using the Abort Execution button. See http://zone.ni.com/reference/en-XX/help/371361M-01/glang/labview_toolbar/ for a description of the Abort Execution button When your program is shutting down, make it output 0 V.

The speed seems fine to me. @Jordan Kuehn, have you tried a different browser/computer?

Could you collect all your data first, and then plot them afterwards? Out of curiosity, what is the name of this other app? It's possible that your other app was especially designed and optimized for one specific use-case (visualizing a huge number of ECG graphs). LabVIEW graphs are general-purpose and very flexible, so it can be out-performed by a single-purpose, less flexible graphing tool.

True. All icons/glyphs/symbols need to be learnt from somewhere first. The key is creating controls that are consistent with what the target audience is already likely to know, and are unambiguous. (e.g. you can safely assume that smartphone-savvy young'ns already know what "white circle on the left" means :D) Back to answering your original question... For user-facing GUIs, I use the Silver push buttons (the middle column of the gallery in your original post) The leftmost columns are too ugly for my liking, unless the customer specifically asks for the old-school look. http://ux.stackexchange.com/ is a good place to find enthusiasts + experts who are happy to share their ideas and discuss yours

That's normal, because plotting 5000 graphs requires lots of computing resources. May I ask why you want to plot so many overlays at the same time? After all, it's very difficult to see them.

To take another page from Google's Material Design, their switches convey state by using colours without "ON"/"OFF" labels at all: (From https://material.google.com/components/selection-controls.html#selection-controls-switch) I actually experienced the issue that @hooovahh described. It showed "Notify me of replies", with an "X" next to it. I wondered to myself, "Does clicking the 'X' get rid of notifications?" because, from prior experience, clicking 'X' closes windows. Thus, I had to play with it to discover its meaning.

Or, embed Google into your forum: https://support.google.com/customsearch/answer/2630969?hl=en

(EDIT: D'oh, half an hour too slow) Naming user events is an edit-time operation. If I write a subVI that generates and outputs a user event refnum, call the subVI twice, and then register both events at the same event structure, I will get two cases with the same event name (which equals the label of the subVI's output terminal). The workaround consumes a large amount of real estate: (Image taken from http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Name-User-Events-at-Runtime/idi-p/2592841 -- ignore the "runtime" part of the title) I haven't dug into VIMs myself yet, but if they provide a nice way to label the output refnum, that would be very very nice. See also this highly-kudo'ed idea, which seems to be catalysed by the desire to name user events: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213153

A very sensible list! Do #5 and #7 could be merged, or at least presented one after the other (#5 sounds like a specific way to do #7) Do #4 should include error messages and error codes whenever applicable. You might also find other useful gems at http://stackoverflow.com/help/how-to-ask Norm's point is a tip for using Google. Type "site:lavag.org ShaunR" into Google and see what happens

I don't have LabVIEW 2015 on my home PC so I can't open your code, but I'll hazard a guess: Is your "recursive" VI configured as Shared Clone Reentrant? This article might lead you to more clues: http://digital.ni.com/public.nsf/allkb/3FBC5856A4BAACB886256D270001A91F I'm not convinced that the error message is talking about recursive object creation, because it clearly flags Abort_EM.vi is the problematic VI. It sounds more like LabVIEW doesn't want to let you call a VI that eventually calls itself again. Do my 2 points above help? However, if it is indeed problematic to include an Abstract Equipment Module instance as a member of the child class, try storing the member as a Variant instead of an Abstract Equipment Module. (You will need to convert the Variant back to an Abstract Equipment Module before running its member VIs).

"Abuse" is such a strong term. I prefer "innovative use", or "thinking outside the box"

Does the user have multiple screens? I've noticed that when one LabVIEW window is moved to a screen with a different resolution and/or different DPI, all LabVIEW windows will change size. (I haven't seen the font shrink by itself without changing the window size, though)

Not directly. Servers are designed to provide data to Clients, not to other servers. If you want, you can write code that uses a Client to read reads the data from one server, and then copy the data to the other Server. However, I suspect you should re-design your code instead. Why do you have 2 separate servers on the same PC? Would it make sense to only have one Server, and put your sensor data under different Folders?