From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Architects Forum

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic Dispatch By Ref Wrapper

This is a utility that I wrote over a year ago to reference wrap my Dynamic Dispatch VIs. Here are the (known) caveats:

  1. It only works on Dynamic Dispatch VIs (difficult to fix)
  2. It only works on Open Projects (easy to fix)
  3. It only works on Classes found in the "My Computer" section of projects (easy to fix)
  4. It assumes exactly one error in, one error out, one dynamic dispatch class in and one dynamic dispatch class out. Any other scenario will cause fire and brimstone to fall from the sky. (difficult to fix)
  5. It suffixes the Dynamic Dispatch VI with a user specified suffix. (easy to change)
  6. It always adds the Ref-wrapped VI to the class library (easy to fix)

Other comments:

  • I use a 1920 x 1080 resolution monitor. Always. You should too.
  • Saved in LabVIEW 2013, Go here if you want it back converted before asking in this thread.
  • The code was written ~ August 2013. The documentation was written today (yes all of it...). Please post if you find errors in documentation, or any other errors
  • Yes I realize my reference closing decisions closely resemble that of a squirrel trying to cross a highway. I make no excuses for why I close a few references and not others, don't overthink what I've done.
  • This uses a top-level VI "RefWrapperGUI" to invoke, it lists all open projects, allows you to select a project, then a class from that project. Once you select the class, you'll see a list of Dynamic Dispatch VIs in that class, select one or more then click the Ref Wrap button. This fit my use case, Darren suggested a quick drop VI but I don't have time at the moment to convert to that.

Finally a note to NI, I've spent roughly a man week on this (partially due to lack of scripting documentation). This utility should not be necessary as there should be a native way for a class to accept either a ByVal or ByRef class. Please don't use this as an excuse to not create an easy way to have ByRef Dynamic Dispatch.

Charles Chickering
Architecture is art with rules.

...and the rules are more like guidelines
Message 1 of 8
(10,981 Views)

OK, so I made a quick drop shortcut with the help of that code as an excellent example. The shortcut still needs work, but basically it takes this:

before.png

And makes this:

after.png

Which, cleaned up, looks like this:

clean.png


code is here:

https://github.com/dsmithni/LVTools-Palettes/tree/dvrqds/Trunk/quick%20drop%20shortcuts/DVR%20Wrap
And you can download that whole repo as a zip here if you don't have any git clients on your machine:
https://github.com/dsmithni/LVTools-Palettes/archive/dvrqds.zip

When I feel more comfortable with it I'll post to the QD shortcut group.

0 Kudos
Message 2 of 8
(8,699 Views)

I love everything about this!

0 Kudos
Message 3 of 8
(8,699 Views)

One change you might consider: If your VI has "automatic error handling" turned off, you don't have to bother with the second "Merge Error" node. Don't wire the "error out" on the right-hand side at all. The error out on the left-hand side of the IPE and on the left-hand side both output the same value. If you are using automatic error handling, you can wire the right side error out to the border of an empty sequence structure and LV will compile that code away (unwired terminals on structures do not trigger automatic error handling. You might choose to always wire to the sequence structure anyway just in case someone toggles automatic error handling on your VI later.

0 Kudos
Message 4 of 8
(8,699 Views)

So the error out on the right border of a dereferencing IPE can always be ignored?  Why is it there?

This is a direct quote from MattP on this subject:

There are some additional error types that can come from the right border node, but this is mostly there (I believe) to allow for more types of errors to be generated in the future if needed. ... It is technically correct, and yes quite clunky, to be merging errors from both nodes on structure exit.


                   
Nate Moehring

SDG
0 Kudos
Message 5 of 8
(8,699 Views)

Yeah, matt and I have talked about that. He misread a line in the original spec document, if I remember correctly--there is only one runtime error right now, and it happens on both error outputs. I'm guessing at this point that more errors are unlikely to be added, making both merge errors kind of useless.

That having been said, I tend to think that having both merges there is the right thing to do, in case the user clears the initial one in their code. For example I've recently seen some vi server calls which don't have standard error in functionality and it would be nice to be sure that the true error (ref==bad) is the one being sent downstream (just noticed my qd shortcut actually misorders them, but ^^this was my intent). Another reasonable option would be to put a case structure inside of the IPE structure and just don't call the code if an error occurs, but I don't know if I'm a huge fan of that either.

0 Kudos
Message 6 of 8
(8,699 Views)

smithd wrote:

Another reasonable option would be to put a case structure inside of the IPE structure and just don't call the code if an error occurs, but I don't know if I'm a huge fan of that either.


                   

This would far and away be my preferred -- why spend a bunch of time continually checking that error and doing other computation work? I don't tend to add such case structures all over my code because they require me to drop them manually and it is easier to just let each individual node check the error and skip, but if something is autoscripting, I think it makes things easier. There's another reason to do the case structure... consider this case:

You have an array of integers wired through a tunnel into the IPE. You have a DVR of an integer. You unlock the DVR and multiply the value in the DVR times your array and then pass the array out.

If you got an error, what should be the value of the output array? Do you really want an array of all zeros? I can think of two common values I would want -- the array unmodified or an empty array. Both of those are easy to achieve with a case structure (one has "use default if unwired" and the other has the array wired across the False case).

Basically, any output tunnels of the IPE whose value is determined by the value of the DVR seem to make the case for checking the case structure once and skipping all work because not every node checks the error cluster at all.

0 Kudos
Message 7 of 8
(8,699 Views)

Fair enough, makes sense. Should be easy to add that, I'll just wrap the initial node selection with a case structure after I've already wired up the IPE.

0 Kudos
Message 8 of 8
(8,699 Views)