Callees Names property node oddity

[Graeme]

Hi all,

With regard to the attached top level VI (Untitled 2) and its subVI (ClusterValueShifter), can anyone postulate why, when the case structure (in which the subVI sits) selector is False, and Callees Names is run on Untitled 2, Callees Names returns no subVIs. Yet, when the case selector is True, Callees Names returns ClusterValueShifter. Incidentally, the unsupported Callees Paths exhibits the same behaviour.

Regards, Graeme.

[Justin Goeres]

QUOTE(Graeme @ Dec 14 2007, 01:37 PM)

can anyone postulate why, when the case structure (in which the subVI sits) selector is False, and Callees Names is run on Untitled 2, Callees Names returns no subVIs.

It's because at some point a couple versions of LabVIEW ago (LV8.0, as I recall), the LabVIEW compiler got slightly smarter and more helpful. Now, when the compiler sees that you've got a constant wired to a multi-frame case structure, it only compiles the code in the structure frame that will execute. As far as the compiler is concerned, at runtime the ClusterValueShifter.vi doesn't exist.

This eliminates one of the popular tricks of yesteryear to guarantee a dynamic VI was in memory: you'd put it in an unused frame of a case structure. That's why when you open code in LV8.0 or later that was written in LV7.1 or earlier, one of the warnings you sometimes see is along the lines of "a constant wired to a case structure was converted to a hidden boolean to maintain compatibility with LV7.1." That preserves the old behavior when the code is recompiled for LV8.0+.

NOTE: You would see the complementary behavior from the Callers' Names property in ClusterValueShifter.vi if you were, for instance, calling it from more than one VI; Untitled 2.vi wouldn't show up in the list.

[Aristos Queue]

QUOTE(Justin Goeres @ Dec 14 2007, 08:09 PM)

This eliminates one of the popular tricks of yesteryear to guarantee a dynamic VI was in memory: you'd put it in an unused frame of a case structure.

The trick still works... you just have to use a boolean control instead of a boolean constant. But the *far* better way is to use a static VI reference (found in the Application Control palette).

[Graeme]

Thank you for the replies, gentlemen. I don't you how you find out all this stuff, but it's greatly appreciated that you pass your knowledge on. The VIs I posted are a snippet from a large top level VI of mine. In that, there are VIs in False-constant-selected cases that are returned by Callees Names, although those case structures sit within other case structures, which in turn sit in event structures in while loops. Maybe there's some sort of difference there. I'll try to post.

I'd always assumed that Callees Names was akin to View-VI Hierarchy, but obviously not. This throws my simple VI cloner that I'd put together. Thanks again.

Graeme.

[Graeme]

are[/u] returned by Callees Names"]

Oops, sorry. In my top-level VI, said VIs also appear elsewhere, but in case structues with True constants wired to their selector. Obviously Callees Names sees those.

Graeme.