Aristos Queue

Hence the reason for my post. Dynamic dispatch VIs seem like a catch 22 with lvlib scope. You are forced to wrap the class to hide just a single VI.

Why isn't protected scope sufficient hiding?

For large projects, this seems like a lot of work to hide one or two dynamic dispatch VIs. It would be nice to control what VIs are visible/exported in the lvlib properties. Any thoughts? I may put this into the idea exchange...

That would be unusual among the world's OO languages. I'm not saying it's a bad idea, but when none of the major OO languages that I know of do it, I always have to ask why. Scope is not one of those areas that is impacted by dataflow.

What you're seeing is the same behavior that all LV controls have. It is why some controls have "Synchronous Display" as an option. The synch display option forces LV to wait until the UI is updated for every write to the indicator. Normal operation will update the UI on a much slower schedule -- so you see big jumps when writing to a Numeric control inside a loop, for example.

If you update your XControl using the Value property instead of using the FPTerminal, I'm 90% certain that you'll get the synchronous display behavior.

To control what is visible, set the access scope. The dynamic dispatch VIs can be set to protected, which is the only other meaningful scope for dyn disp -- it doesn't make sense to have a dynamic dispatch method that cannot be overridden by children.

There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

Congratulations, Vivante.

Reinstallation isn't going to help unless you've been modifying the VIs that are part of your installation. No, this is far more likely to be something you need to deal with in your code and/or app build setup.

Try adding instructions to always include the panel. If that works, you can either keep that solution or look at your VI and figure out why the panel is required. You might post the block diagram here... someone here might spot the key node.

Have you turned on Automatic Error Handling both in Tools >> Options and on all VIs in your project? You can quickly write a "get all VIs in memory, turn on automatic error handling" VI to do that rather than doing it by hand. That will make an error go off if there is some place where the errors are being dropped.

If you have access to the Desktop Trace Toolkit, that will add an entry to the log file every time an error is generated at the point of original error generation, assuming you have debugging enabled on the VIs.

Maybe it's related to using the UI thread in the DLL call?

Use of the UI thread is not enough to trigger the loading of the panel.

No seriously, I don't see what feedback nodes bring to the table versus shift registers when you need to use the output outside of a loop.

1) In pipelining, particularly common in FPGA, they're critical. Of course, those are configured for feedforward, not feedback.

2) I'm told (and anecdotally find to be true) that electrical engineers are used to reading the feedback notation in other schematics. They read them much easier than the shift registers.

I usually buy the "it is too complicated for the masses" argument until I try using XControls. Compared to those XNodes are a walk in the park.

Ah, but XControls don't have the potential to corrupt your VI if you do them wrong. There's a big difference between "complex" -- which is a reason to put a good UI on something but not a reason to never release it -- and "flakey around the edges" -- which is a reason to keep it in house.

Yes, those events will always come in the predictable order, as asbo postulated.

asbo: Never forget that "for" can be abused as "while" in a lot of C-like languages. Read it as "for(;imstuck;)" where imstuck is true. Semicolons would be needed in C++, but there are other similar languages where you wouldn't need them.

VIs that are built into an executable have their front panels deleted by default unless they are the top level VI, a dialog VI, or have a linked control reference on the block diagram. The Median.vi does not meet those requirements, so its block diagram is stripped out of the EXE to make a smaller EXE. You're doing something in your application to try to open the front panel of this VI -- perhaps getting a control reference or using the Set Control Value method? Whatever it is, you need to modify your AppBuilder spec to tell that VI to keep its front panel.

If you like the Enable terminal, there's a feature coming in LV 2012 to solve the tunnel output consistency problem. Take a look at the Upgrade Notes when you get your upgrade later this year.

Hey... at least you guys have gotten me to the point of admitting that XNodes even exist. Time was I would have accused you of hallucinations and swamp gas reflecting the light of Venus for believing in XNodes.

lordexod: The XNode tech is reserved to National Instruments for a long list of reasons, not the least of which is that it requires some significant contortions to avoid the traps and pitfalls of working with them. XNodes invoke G code to do their work. There are various operations that are not stable to do while LV is doing certain operations (loading a VI is not always safe, for example, depending on what else LV is doing at the time). As a matter of fact, XNodes have been mostly abandoned by NI for further development ourselves because of their issues. They work great for some things, but poorly (or crashily) for others, and it is very hard to tell in advance whether a given use case will turn out to be the former or the latter. We'd like to have a more complete "G written in G" solution, one that we could release to customers, but XNodes aren't it.

Yes. I do.

No, I won't share.

You say that this subVI acquires data from an instrument. Do the other functions also acquire data from an instrument? Is it possible that this subVI is somehow badly written in that it is locking the instrument so that the others cannot access the data? Is it possibly closing the instrument reference that the others are using? I would check all of the "error out" terminals for all your VIs and see if any of them are returning an error that would be useful... your exported functions probably aren't returning the error to the caller, but on their block diagrams, add a Simple Error Handler.vi that collects all the errors generated on that diagram and see if any of them report when you build the DLL.

You know that removing this subVI makes the rest of the exported functions work correctly. That's an odd workaround to have discovered, which implies to me that something happened that made you test this theory. What did you observe that made you suspect this subVI might be contributing to the problem? Knowing that observation might help the rest of us suggest how this subVI is interacting with the rest of your application.

Or maybe The Captain's LV Patch would be better

Nah... that one just helps you stop smoking. :-)

AQ has mellowed since then and would probably not say the same thing today, but it still is important to be aware of the implications of using type cast.

After I finished crying, I added an autotest to LV's nightly test suite just to make sure if anyone did try to change the private fields of those two classes in a way that they no longer coincidentally lined up, we'd see the crash on our end long before release. So far, so good. No one has felt the need to refactor strings. I still don't recommend it, which is why I was waiting to see if the "copy a constant with the right font" workaround would suffice before mentioning this dark alchemy. :-)

Why are you still using VITs for dynamic instantiation of VIs? Of course its slow! Instantiating a new VI from VIT creates a wholly independent copy of *the entire VI*. Contrast this with creating a new clone of a reentrant VI, where we only clone the dataspace and the front panel if and only if its open. We never clone the block diagram, just draw it in two separate windows.

Replicating VITs was a practice that should have largely stopped in LV 8.0 unless you are scripting new VIs as part of an actual "create me a brand new VI in the editor" tool. There are some edge cases when you're actually scripting new controls, but most UIs don't use that approach because it only works in the full dev environment, not the runtime environment. So for UI work, stick with reentrant clones.

This is why going from .VIT to .VI has an impact -- instead of copying the VIT to create a new VI, you're just cloning the reentrant VI.

Unfortunately, not everything you can do in the editor has been exposed through scripting, and this is one of the holes. Depending upon what you're trying to script, it might work to have a template VI that has a constant on it that already has the font style you want... instead of creating a new constant and trying to set the font, copy the constant from your template and just set the value. Obviously that won't work if you're trying to set an arbitrary font, but if you have a specific font you want to be able to do, it works.

"Everyone expects it, so this year, we'll prank them really good... we won't have one!"

"Yeah, that'll really wind them up for 2013!"

We changed the EXE format specifically to deal with the "multiple VIs have the same file name" issue. Turn the compatibility mode off, fix your paths, and then the system should start working for you. One function you need to know about is "Application Directory" -- it's a node in the palettes. In the development environment, this is the same directory as your project (assuming you're in one) and in the built-EXE, this is the same as your EXE. This makes writing dynamic load code a lot easier. If you want to dynamically load VIs that are part of your EXE, just calculate them as relative paths from your top-level VI. The same relative paths will be maintained inside the EXE as you have before you build the EXE.