Better Context Help for AF Send VIs

[CaseyM]

When I create a public API method for an actor it's very nice to have the VI description populated for use with the Context Help window:

However, once you create an AF message from that method, other actors will generally be using the Send [VI Name] method instead of the payload method itself and the context help for the Send method is decidedly less useful:

Wouldn't it be nice if the send method automatically appended the payload method's VI description so it looked something like the following?

I've actually written a VI package that will do this, but in order to accomplish it I ended up modifying the MessageMakerProvider and MessageRescripter project providers. It's workable, but it's really only reliable for the one specific version of LabVIEW in which it was developed so it'd be much nicer if NI implemented this out of the box.

[CaseyM]

---

Another suggestion is making a right-click item called "Open Do.vi".  Called on any library method, this would open the block diagram of the Do.vi method of the same library.  This means fewer steps to see the actor method description.

---

Funny you should mention that. I actually wrote a right-click plugin that does something very similar - instead of opening the Do method though, it actually opens the payload VI's block diagram. But again, I still feel like there are ways to get you close, but I'd like to see this type of feature available out of the box.

[CaseyM]

What we probably need is a whole different Idea Exchange entry that is "Let me put some tag in Context Help description of VI X that tells LV to copy all the text from VI Y into this location when it is displayed in the CH window." AF would then set the text of the Send VI to be "Sends the message to trigger the following method: <VI=".\relativepath\Method.vi">"

...

Obviously this would be a much larger LV change than just rescripting the CH, but would solve the "two sources of truth" problem, avoid introducing another reason to re-script, and would have wider utility beyond the AF.

---

 Now you're talking!

[AristosQueue (NI)]

"note I proposed a structure"

Ah. Missed that. Don't be subtle the same week LV launches! I'm jumping a higher-than-normal number of forums right now! 🙂

Yes, that's a good idea. Seems like it would kind of look like some kind of Lambda or Closure structure where you locally define the function that will be invoked elsewhere. Might even be something that I have PNGs drawn up for a future-LV proposal of mine. 🙂 One limitation I haven't really come to grips with is the ability to send across the network. A purely data message is fine. A flattened function becomes a virus vector, even assuming there's a good way to encode it. So it is an approach to scripting messages that would be really great locally, but I'm not sure it could be used generally without breaking the general portability and receiver-target agnosticism of the AF.

[CaseyM]

Now you're talking!

---

Actually, I could see this opening up a new can of worms when you have people copy a VI but failing to change the tags. I guess that's not so different from what happens without tags though.

[AristosQueue (NI)]

(Note: The binary code would not be embedded in every flattened closure message. That would be stupid... I don't want anyone thinking I've missed that point. Each message only needs the closure parameters... the code only needs to be loaded once on the target. But across the network, the method would need to be cross-loaded at some point, and that opens the door to arbitrary code loading in any reasonable framework. This is totally the wrong forum to be discussing this, but I realized that my previous post could look really dumb without context.)

[AristosQueue (NI)]

> Actually, I could see this opening up a new can of worms when you have

> people copy a VI but failing to change the tags. I guess that's not so

> different from what happens without tags though.

And you'd have an error message telling user that things were out of whack instead of just contradictory or stale documentation that user doesn't think to question.