Val Brown

Yes they were, as was Lord of the Rings and the Hobbit, to name another few popular titles. Notes From the Underground is quite stark -- but a classic -- and I think the "easy read" that really got to me recently, it would be: "The War After Armageddon".

And vice versa so I think this is really a question of scope or scale of definition. Seems kind of like counting dancing angels on pinheads....

Sorry I did the quote then somehow didn't quite add the comment.....maybe somebody can clean it up. I can't seem to find the edit option. In any event, you have the history reversed -- and it IS about history. The point is that was the ONLY way to do it way back when (at least AFAIK) and so it remains in some legacy code but another reason is that one just might want to trap "error" -- even if it's because of releasing the queue -- and not exit all of the parallel loops but perform some other kind of "recovery" operation.

I have used that exact template to terminate parallel loops. In the past -- before Event Structures (and some other tricks...) that was the only way to guarantee shut down of parallel loops that received inputs from queues as well. It's a solution that goes WAY BACK to LV5 or so...

Yes so am I. That's why I said may....

Yes I guess Evil AQ can be snarky.... So again, from my perspective LV is a pure dataflow language but may be purely hygienic. ooops I meant may NOT be purely hygienic.....

So, if I've followed ALL of this, what we come down to is: LV is a pure dataflow language with an implementation of references that is inherently dataflow and not raw pointers. Obvious when you "read the manual" and such but that option is TRAINED OUT by traditional CS approaches based on text-based "jump anywhere" languages that allow for raw pointers and, thereby, leave the programmer with the mess of memory management, ah, I MEANT to say: with all of the options of deciding how to manage memory everywhere still available to you, along with the responsibility for actually doing ALL of that. In other words, coming from a traditional "jump anywhere" architecture being ASSUMED, LV can seem quite "limited". Recognizing what it actually IS, LV is an inherently elegant implementation of dataflow. Hmmmm, maybe I should ask Evil AQ about all of that......

Now that kind of skinnable, thim UI sounds very interesting. Any examples you can post?

I don't LIKE it -- being in the same situation -- but it makes perfect sense to me and, as has been pointed out, there isn't a whole lot of money involved for NI in the process. Certifying others is a very time-staff expense operation, esp to set up initially but also to maintain, let alone extend, over time.

Not only in 2010, but also in 2011. I suspect that, if you had migrated the code version by version as I suggested, then you wouldn't have gotten the broken arrow but I guess it probably also does depend on the particular CIN. In any event it was good that you got ahold of the original developer(s) and they were able to resolve the issue for you.

This is very cool - both the code as last posted but also the overall process of review demonstrated in this thread.. I'm looking forward to (now) having more time (and energy) to participate in these kinds of discussions. Kudos to all involved!

This is an example , IMHO, of a unique situation that entails a purely local solution - what I would call a pipeline filter from my Unix days. The OP's original suggestions should definitely NOT be included in OpenG, but the idea of throwing an error on this condition should be.

I'm unaware of any specific, inherent limitation in either 2010 or 2011 re: the use of CINs. In fact, I have a legacy project that uses one CIN and I've had no problems at all with it in 2010 and 2011. I suspect that the problem is more connected to how you are referencing the resources needed by the CIN. FWIW, if you can, I'd suggest migrating that CIN -- called in some test program -- through each of the intervening LV releases. Perhaps that might help resolve the problem or, at least, highlight more clearly where the error is really coming from.

Ah so what do you use then to generate them?

From my perspective, again, this would be an example of "doing it right" -- even if it involves some work now (cf Ton's comments above) it still would be the most consistent and comprehensive way to organize OpenQ. But then again I don't have years of legacy code using OpenG so I'm certainly not down in the trenches on this one.

Do you an AES key generator in native LV?

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

And I suspect -- but COULD be wrong -- that this is because iLV is "really" byval (meaning dataflow optimized) and not byref, so inplaceness counts in many, many ways...

I think so too, FWIW.

Good, then the short answer is: yes. Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

Precisely so. And then, if for some reason you (a user) did make a "local" modification to some underlying OpenG VI, you would put the modified code into user.lib, leaving the original OpenG untouched in vi.lib.

In the past I was never able to get it to function correctly via ODBC to serve as a replacement for MS Access so I'm very interested to hear how this turns out.

This all sounds like a very good plan.

I agree. This is one of the best decisions that NI has made in re: to the LV workspace and it's one that IMHO should have already been made when those tools were originally released.

As do you -- so the ten of you get it and it's obvious that you're right handed when you count that many items..... :lol: