Classes should not be locked when added to multiple targets

[MGiacomet]

Let's say you have a class you are developing and want to reuse it in multiple targets, particularly if you work with RT targets. You want to do most of your troubleshooting and development on the PC (assuming that the class has nothing hardware-specific) and when it works well you plan to do some final testing in the actual RT target.

So, you create your test project, with the PC target (with the class and the tester VI). Now you add the RT target and reuse all the VIs and the class. BAM! LabVIEW locks the class and you can't make any more changes until you delete one of the targets of your project. You can't even create two projects (one for the PC another for the RT), because the class will be locked.

NI has an "explanation" here http://digital.ni.com/public.nsf/allkb/219A8BB7FD8EF0D9862571840053A5E9 but I find it lame, because a similar situation described in the article happens when modifying typedefs (some VIs get temporarily "broken" until you Apply Changes in the typedef editor).

Please do not lock classes or at least have a button/command to unlock one of them.

[fabric]

I agree that the explanation is a bit unconvincing... Surely it would be possible (and extremely useful) if the user could have the ability to unlock the class in one application instance? That would nullify the idea that "...resolving those changes is impossible since the order in which the changes are made affects the final outcome of the class. "

[Good_Times]

NI continually discards the core principles behind code reuse with problems like this.

[Neil.Pate]

Came across this today, rather annoying.

Is there any sensible work-around for this?

[AristosQueue (NI)]

> Is there any sensible work-around for this?

Sensible? No. You can close your project, open a new project that has the class in one context, save your changes, close that project and reopen your original one.

Sorry -- that's the way it works. When I put this lock in, I honestly thought that by now the lower level systems that required it would have been refactored. Unfortunately, all these years later, the code still isn't there to support edits while loaded in multiple contexts. I have moved on to other projects and no longer work directly on the LV classes code, but I continue to remind the developers that this is a significant pain point for LV classes.

Side point, regarding the original idea: The typedef editing situation and the class editing situation are not analogous. Typedefs reapply changes to VIs without going through intermediate changes -- it's actually one of the drawbacks that get a lot of complaint about working with typedefs because it can lead to one set of VIs getting modified one way and another set of VIs getting modified a different way. Classes handle that problem, but at the cost of the multiple edit lock. Ultimately, there is a fix possible, but there's a lot of code in the way and this just hasn't gotten priority.

[MGiacomet]

Yeah, the typedef is also a bad implementation with incomplete propagation, at times. But that's another story...

If the "elegant" solution you envisioned (and hoped) to refactor the lower level code isn't there for YEARS, how about just removing the lock you put in and is causing this trouble?

This is a real pain!

[AristosQueue (NI)]

MGiacomet: Your comment implies that I put the lock in there just to be annoying. No, I added the lock because LV would crash without it. 🙂

The refactoring I spoke of would allow the system to support the editing in two contexts. Currently, that's just not possible.

[MGiacomet]

Well, perhaps crashing LabVIEW would be a better solution! Then NI would actually do something about it in a somewhat timely fashion.

The way it is it makes it very hard to work with classes and turns a powerful technology into something that one will use when "oh, well.. I guess this time I have to use classes... and live with its annoyances."

This is a typical example of a good idea gone bad that "throws out the baby with the bathwater". In other words, just releasing some implementation of OO just so sales can say that LabVIEW supports OO detracts the technology (not to mention the customer's lost time when having to deal with this).

[AristosQueue (NI)]

> Then NI would actually do something about it in a somewhat timely fashion.

Probably we would add the lock. Catch 22. 🙂

> The way it is it makes it very hard to work with classes

Yes. Yes it does. No one is denying that. It's all a question of the resources available to address issues.

> This is a typical example of a good idea gone bad that "throws out

> the baby with the bathwater". In other words, just releasing some

> implementation of OO just so sales can say that LabVIEW supports OO

> detracts the technology (not to mention the customer's lost time when

> having to deal with this).

To be fair, our inital polling of RT and FPGA users was that they would never in a million years use LV classes when we released 8.2. "That's something for desktop and high power environements. We don't do that kind of architecture at the low levels." So for the first release, classes couldn't even deploy onto other targets. For LV 2009, I convinced everyone that there was just enough demand from some advanced power users to spend time upgrading the compilers and deployment systems for RT and FPGA to accept LV classes. There are many classes that are needed only one one system or the other that never cross that boundary and so never hit the lock. Still adoption rates were very low.

This wasn't done just so NI Sales could check a checkbox. My team wanted to release as solid an implementation as possible. We encountered this subsystem that we did not have the manpower to fix. Given the survey data that we had, this seemed like a more than reasonable workaround, and it was my call personally to do it. There are only so many developers and so many hours in the day.

Now, I have continued to tell management "this needs to be addressed eventually." But I have only gotten a significant number of people hitting this lock within the last year as we finally have OO adoption rates up. In terms of prioritizing which fix is needed when, I'm hard pressed to say that my management made the wrong call. Yes, we're likely going to end up behind that curve by a couple years, because we won't have a system that fixes that problem until there are significant numbers of customers complaining about it. But in terms of the resource allocations and all the other features that were done in the interim -- features that helped push LV class adoption at every level and not just the multi-target case -- the trade-off seems like the right call.

LabVIEW 2013 has the Customer Experience Improvement Program (aka CEIP) code that is an opt-in program asking you users to let LabVIEW send back to NI user data from time to time about what parts of LabVIEW you are using. I have gotten onto that list information aobut classes used and which targets they are deployed onto. That will give us more firm numbers to work from. While I expect the LV Classes on desktop to be much higher than my peers expect, I expect the classes on the targets numbers to be quite low. Now, you can say that the adoption doesn't happen because of usability problems like this lock -- chicken-and-egg problem. But there are huge swaths of classes that would only be on one target, not back on the desktop. If we're not seeing those classes, then we know we still don't have mental penetration into those users about the utility of classes. Until we see that, getting pressure to fix the multi-target lock issue is going to be hard.

This is the reality of software development. I'll stand by the decisions we (often I) made in the OO development process. I've handed most of that off to others at this point -- they're good people who really do aim to make the best LabVIEW user experience possible with the resources available, and I expect them to make the same trade-off evaluations in the future.

But please do tell your Field Sales Engineer that this is hitting you. Despite all the foregoing, I really do wish we could get this fixed.

[Mads]

Where is the emoticon with a head banging against a wall? I know we have it on LAVA, but we should have it here as well.

LVOOP is full of unexpected limitations

[Sam_Sharp]

I too have just been stung by this - I have a class that's used mostly in Windows but I have a public method that returns a constant (FIFO packet seperator) and whenever I open the FPGA VI the class gets locked and the only way to unlock it is to exit LabVIEW entirely and re-open. Not even closing the FPGA VI is sufficient.