Aristos Queue

His refnum is explicitly not the same. It's TCP or UDP or whatever.I should note, regarding my solution, that each child class would have to cast its reference as an int32 in order to return it to parent. Jeffery raises the point about doing more than just checking for Not A Refnum... i.e., checking if a non-zero refnum is still valid. Very important, for (imstuck): read this please: http://lavag.org/top...ur-app-at-risk/

Add a dynamic dispatch protected scope "Get Refnum" to the base class. Make it "Must Override". Call it in the Is Valid implementation.

I did some testing... everyone was using Match Pattern... I found a code snippet that was faster than that in every scenario I tested: I wasn't sure if it was only prefixes that were being sought ... all the test harnesses only created prefix test cases. If you want "anywhere in the string", then this doesn't help, obviously.

Right idea, wrong actual solution. Instead of "Always Copy", use the "Mark As Modifier" option on the Inplace Element Structure instead for this purpose. It signals the same "this subVI could modify this value" on the conpane without introducing an unnecessary copy on No Error cases.

Or name your classes differently. I use a combo in the actor framework... there's the "Actor Framework.lvlib" that wraps the generically named but always used together "Actor" and "Message" classes. But the "Batch Msg" class is off on its own, as that's a bit less generic. Chance of collision? Yes. Fact of life, I'm afraid, since LV's libraries aren't merge-able namespaces.

We have never introduced any sort of "sealed" concept into LabVIEW. If you do not wish to have to design for inheritance, then you avoid having any dynamic dispatch methods or any protected scope methods. I'd like to someday add "sealed", but it's not been a priority.

If LV ran the call in a separate process, would it be able to share memory? I don't think it can... even if LV allocations could be shared with the process, allocations from that process could not be shared with LV because those allocations would evaporate when the process exited. That would be a pretty hefty penalty for calling libraries if all strings and arrays triggered data copy.The only real solution would be for all of LV's VIs to run in a separate process from the editor, something that other IDEs do but LV does not because historically it has introduced too many usability issues for which we did not have good solutions. Over the years, various solutions have been found, but at this point, the unity of the execution environment and the dev environment is pretty deeply built in and it would take a rewrite of a substantial part of LV to separate those.

I didn't count "signal-able" as the same as abortable.

Remove Frame is not implemented at all, not even internally. Pretty much all of our scripting operations are constructive, not destructive, so it doesn't surprise me that this got missed for so long.

The brand new Discovery Telescope uses a heavy amount of LabVIEW. LAVA user Paul_at_lowell is key to that project. For those who were at the USA 2012 CLA Summit, this is the telescope that was the motivation for the third user presentation in the morning. Looks like congratulations are in order based on today's slashdot article: http://science.slashdot.org/story/12/07/23/2135258/discovery-channel-telescope-snaps-inaugural-pictures "Two decades ago ... Discovery Channel teamed up with Lowell Observatory and embarked upon a $53 million adventure: the fifth largest telescope in the United States funded entirely without state or federal money. The very first photos snapped with its 16 million pixel camera are in and they look beautiful. Yet to be seen are the simultaneous spectroscopic and imaging observations that should be provided to researchers by the DCT's Ritchey-Chretien instrument cube. Located near a dark-sky site (Coconino National Forest), scientists hope to use this new telescope to answer many research questions including how our solar system formed and how dwarf galaxies evolve. For more telescope porn, check out the DCT's photo tours. Luckily 'the process of planning and building the telescope is due to be featured in a one-hour Discovery Channel documentary set to air in September 2012.' Perhaps there is hope for Discovery Channel to return to its former glory?" Well done! Well done indeed.

The following post is an area I am *not* an expert in. Please contradict me if you know better... asbo: I'm not sure if this is the case with this error, but my understanding is that many of the errors reported by DAQ are designed with real-time in mind where even in the error case they avoid allocating memory -- i.e., no strings in the error code clusters. This means that all you get is the static text that can be obtained from the error code number itself. Much of the DAQ code was written before there was a conditional disable structure, so special casing the behavior on desktop wasn't an option. I have seen some recently written VIs that behave differently and give more helpful errors in the non-RT case.

Bought my shirt. And tickets.

It seems I messed something up... this bug is not resolved in 2012. I thought I had it fixed. And it was a double mistake: I even managed to mess up the test suite function that would have told me that it wasn't yet fixed. I am sorry.

Relf: I expect you'll be skipping the NI Week keynotes, then?

Lordexod's solution isn't going to help you. If the VI that you're wanting to run is the exact same as the one that you have in the static VI reference, then just get rid of the Open VI Reference node entirely and wire the static VI reference directly into the subpanel invoke node and the Call By Reference node. Update your Build Specification to tell that VI it to keep its front panel. If the VI that you want to load is not the exact same as the VI that you're using in the static VI reference, and the VI is going to be outside the EXE, that's the only time that you have to use the path. Use this code for opening the VI reference: The Application Directory function will be relative to your project file in the dev environment and relative to the EXE when you build.

No, CLNs were never abortable. Once you're out of LV's execution system, there's nothing LV can do but wait for the code to return control to us.

I figured by now you'd have fixed those FP terminals. Who can tell what they are without the icons? ;-)

Hm... I was thinking in terms of monitoring any arbitrary VI, but this is an interesting approach. An XControl gets an event when the owning VI changes state, so if you put an XControl on the front panel of the VI you're interested in, that XControl could fire an event when the owning VI changes state. That avoids the overhead of polling.The downside is that the XControl is going to force the front panel of the VI to always be in memory, which creates a performance hit when calling the VI since time is spent updating the front panel. If the VI you're interested in is one that has its front panel visible, this is a good idea. You would create a user event in your monitor VI, pass that user event to the VI-of-interest, which would put that user event refnum into the XControl (probably through the FPTerminal). Then when the XControl gets the "owner went idle", it fires that user event.

You could build a polling loop that checks whether a VI is still running and then generates an event.

I'll be giving away one of these:

You say you don't detect the zero until after point 3... does that mean that you probed the cluster coming out of step 2 and in that probe you see data but you probe the values coming out of the Unbundle node and you see zeros?

That's nice. Would cause problems for data serialization.

I concur with Paul.

CRelf: It's not easy, but it is straightforward: https://decibel.ni.com/content/docs/DOC-19176 I think it addresses exactly what you're trying to do. At the very least, there's info therein not covered by the other posts in this thread as far as I can tell. Honestly, though, my question would be: Why are you using the "append prefix" feature? If you just stop doing that, everything works in your project. If you need a namespace to prevent collisions with some other version of your files that may be used simultaneously, put a library into your *source* and add all the files to that.