search

JKISoftware / JKI-State-Machine-Objects

Object-oriented framework for LabVIEW based on the JKI State Machine
BSD 3-Clause "New" or "Revised" License
95 stars 54 forks source link

Upgrade Tests for modified namespacing of dependencies shows upgrade issues #67

Closed francois-normandin closed 4 years ago

francois-normandin commented 4 years ago

Describe the bug Dependency.lvclass has been renamed to SMODependency.lvclass in this tentative release. The class was assumed to be called only at the framework level, but it is actually part of the output terminals of a protected (overridable) method, which causes problems.

(Same with Façade, Terminal, PublicEvent and Attribute classes.)

**Version impacted migration to 1.4.0 (Release candidate) from any prior versions

francois-normandin commented 4 years ago

@jimkring Do you know of a way to change the namespace of classes where LabVIEW would find those classes on first load? I thought that moving a class into a lvlib would relink automatically, but that is not the experience I just got from testing the 1.4.0 beta branch for upgrade path from 1.3.0 to 1.4.0. Pending a proven method to do that, I've reverted all the classes to be as they were in 1.3.0.

We had discussed how Terminal and Attribute were very generic names that might cause collisions. I'm interested to learn what you and others think of that. Is it a remote-enough possibility that we should leave it well alone for now?

jimkring commented 4 years ago

Hi @francois-normandin

Do you know of a way to change the namespace of classes where LabVIEW would find those classes on first load?

I'm not sure exactly what you're trying to do -- it sounds like you're trying to figure out a way for users who are calling existing code to automatically relink to VIs that have been namespaced inside an LVLIB.

I think that if LabVIEW is looking for VI on disk and it finds a VI in the right (exact same) location on disk, but inside a different LVLIB, it will relink to the VI on disk (even though the namespace has changed). However, I also think maybe this only works for target/sub VIs that are not already inside an LVLIB, and was a mechanism by NI to allow them to put VIs inside LVLIBs and have the callers automatically relink to the VIs after they were added to LVLIBs.

I've never really used this "feature" of LabVIEW -- I think I only hear Aristos Queue talk about it...

francois-normandin commented 4 years ago

That's exactly what I was trying to do and when I tested it, I was surprised it didn't work. I was under the impression that it worked one-way only (from no namespace to being namespaced inside a lvlib) but that was a wrong assumption. I can't remember where I heard that from, but I guess I interpreted the statements I heard through the wrong filter... I'll keep looking for that topic, but otherwise I guess we have to leave the namespacing as it is, at least for version 1.x.