mje

When? But? How? I swear I tried that and got a broken wire... Thanks Ben!

I have a string containing a task name that is serialized to file. I'm currently just casting it back to a task and all's well: But is there a better way to do this?

For those keeping track, version 1.1.4 is a minor update: Fixed a bug in MessagePump::LockQueue.vi, which resulted in no error being returned if the lock operation timed out and the default error code was used (0). By default, error 123 will now be returned on a time out. This fix ultimately affects MessagePump::StartPump.vi which will now properly return error 123 if it is called on a MessagePump which is already in use. Removed an unnecessary case structure in Callback::DoCallback.vi -m

I recall the term task was used quite a bit back in the day, but this might be due to the same reason as we throw the term thread around so willy-nilly today (before multithreading was really an option, the feature to talk about was multitasking)... I in fact still use the term task, but I frankly have forgotten the details as how LabVIEW's internal scheduling compares the multitasking operations of an OS. I'm not sure if the term is technically correct when applying it to a LabVIEW context.

You can make Object methods reentrant. If you configure the reentrancy to allow instances to be allocated dynamically, you should be able to spawn as many versions of the VI as you need. If reentrancy is something that is new to you, I can elaborate. However, in the example you show, graphDisplay.vi runs synchronously, execution won't continue in the calling VI until graphDisplay.vi returns. Even once reentrancy is set, you still will only have one running VI showing at a time, other front panels won't be executing (might be what you want though?). If the VI needs to keep running, you'll need to create a wrapper VI that launches graphDisplay.vi asynchronously so you can have N instances of the VI spinning in memory simultaneously. Making an asynchronous call isn't too complicated, here's a screenshot from a framework I use that does exactly that: The key is to supply a value of 8 when opening the reference, which allocates the necessary data space and prepares the VI to allow multiple calls, then when using the Run VI method, to not wait until the VI is finished. Does that help?

I love it!

I was under the impression the whole 32/64 bit thing was no different than Windows/Mac/Linux/Etc. A given VI will have the source which has absolutely no affiliation with platform or bitness, and riding along side the source is (among other things) compiled code for whatever platform/bitspace it's being edited on. If opened in a different environment where the compiled bits don't match, it's recompiled as necessary. Pretty much what gmart said. The whole bitness is kind of moot, LabVIEW's been handling multi-platform like this for ages, bitness is no different? Want a Win64 build? Build the app in LV64. Mac? Build it in LVMac. Win32 exe? Build in Win32. One source to rule them all. Exceptions being if you have bit/platform specific code that you have written. But that's what symbols/etc are for.

Also check out vi.lib\Utility\VariantDataType\*. There's a lot of useful VIs in there. Specifically for your case, GetTypeInfo.vi.

No offense taken...I'm just saying that looks wrong, but it has been a long time since I've used both C and LabVIEW at the same time. Your function declares arr as an int**. NumericArrayResize is expecting a handle, but instead you're providing an int*** (by passing it &arr). Sure you cast to a UHandle* so the compiler won't complain, but they are most certainly not compatible and not the same. I don't know exactly what a UHandle is, but I expect an array handle should have information on the size, rank, as well as the obvious array contents, and I suspect other private info as well...

_declspec (dllexport) int trial(int **arr){ MgErr err = NumericArrayResize(iL,1,(UHandle*)&arr,10); It has been almost a decade since I've done any C-based NI stuff, but this line strikes me as odd. You're passing the address of arr to NumericArrayResize (that is an int*** cast to a UHandle*) which will be somewhere in your call stack. If this memory is manipulated, a crash would be one of the better things you can hope for. Do you maybe have an extra level of indirection in that statement?

Can you elaborate on this? Is it the coding that gets mixed up or does the event structure itself dispatch the event to the wrong frame? As for distinguishing the events, can you rename the wire via a cast? It's ugly, but might solve the problem of having similarly named frames I'd expect? -m

I'd be surprised if a parallel loop would be ideal for this case since you can't define the array size. I'd use VI Server to launch up to N versions of the VI asynchronously. SubVI A takes the array, iterates on each element. Each iteration opens a reference to the VI, supplying the proper argument to prepare it for re-entrancy (Options |= 8), sets the appropriate control values via an invoke node, then the VI is started (also via an invoke node) instructing it to not wait for a return. Return values could be handled via a queue, which SubVI A would have to properly reassemble in the correct order before it returns. Ugly? Depends on your point of view. The only thing I don't like about this method is how you have to pass parameters by setting control values via an invoke method. Slow and clumsy, I don't know how well it would work in a tight loop. What I've always wanted was the ability to do stuff like this directly via the Call By Reference primitive, but that can't handle asynchronous calls.

It's pretty easy to include any arbitrary file into a build...once you've deciphered the arcane method to do so. First thing you need to do is add the respective files to your project (even if they're completely unrelated to LabVIEW, such as text files, jpegs, whatever). Then head over to the Source Files category. Here you can click on any item in your project, and force it to be included if you pop it into the Always Included box. Then, in your build specification, you need to check out the Destinations category. If you just want to use the Data directory (which by default is called the Support Directory), that's fine, nothing else to do. But you can just as easily add other destinations, such as documentation, library directories, etc. Each Item you have under the Destinations box will be available for you to select as a destination in the next step. Once this is done, head over to the Source File Settings category. Click the item in the project hierarchy you're interested in, and verify the Inclusion Type that you've declared previously (I know...it would be way easier to be able to set it directly here). Below that box is a combo-box that will allow you to set where the item goes, each item in the box will have been defined earlier when you were verifying the Destinations settings. Clear as mud I hope? NI made the process way more complicated than it has to be in my opinion.

I would expect that if there are no registrations for an event (be it dynamic or static), firing it is essentially a no-operation? At least that's how it should be, there's no use queuing an event if there's nothing to signal it with...

I've updated the submission to include a fourth example demonstrating the use of Callbacks. There code for the core classes has not changed, they are identical to the 1.1.0 release. -m

Is this presentation available for those of us who couldn't make the live version? Link?

Cat is correct. Arrays require continuous blocks of memory. Other languages have things called lists that allow you to load large sets of data in non-continuous memory, but LabVIEW has no such construct built natively into the language. These lists however are not arrays, and do not allow efficient random access to your data. Do you need to load large amounts at once? Standard practice is to read the file in tiny chunks and iterate through the file while running whatever state calculations you need. Or do you need more random access to the data? In that case properly defining your data structure can allow random access to any element on disk with a little bit of math, or alternatively you might be able to "map" your file out ahead of time to allow random access to variable length data.

Indeed, common practice is to manage the closing of a reference from the same scope which opened it. I follow this in *any* programming language as best I can. AQ mentioned class/DVRs often need to break this rule. I've also found the need to break it when making asynchronous calls where the caller does not wait for a return. As is always the case, you can't really define a steadfast rule.

I'll agree. I'm glad DVRs are there, but have yet to actually implement anything with them. Over a decade of LV programming has taught me interesting ways to keep my logic mostly value based. However, I acknowledge that DVRs have their place and I think LV is a better language for having them. I think a lot my lack of use of DVRs (or the fact that nearly a year later I'm just starting to play with them), is that there is already a lot of reference types floating around that let me do most of what I need to do. The advanced synchronization features I use daily (queues, notifiers, events, and even VI server) can suffer from the same deadlock problems if implemented poorly, yet have become part of the most fundamental programming architectures in LabVIEW. As for the windowing mess...all I really want is a distinction between panels, diagrams, controls, and other window types in my task bar. Give me a different icon depending on what window type it is...even better yet, give me the icon of my VI/Control in the task bar. That, and make project explorer windows floating (always on top). Please, for the love of sanity.

This I believe is true, but an IPE (in-place structure) will only fail to obtain the lock if it's supplied with an invalid reference: the DVR has been deleted, a Not A Refnum (or similar) was supplied, etc. An IPE will only block (wait, or "freeze") if another IPE is currently working on the reference (this is not an error). The IPE will signal (resume execution) when the reference becomes available again. A semaphore is traditionally how you protect resources like this, but there's a semaphore inherently built into the DVR as only one IPE can access it at a time. Under most situations you shouldn't need to protect the DVR with an explicit semaphore.

Cute, Dak. I love the fine print.

I've hit this one before and it drives me crazy. All I can say is the behavior has been around for a long time. Way before 8.6. Sorry I can't offer anything constructive. If it were easy to hook up .NET objects to event structures, I'd have abandoned the LV style lists ages ago, I can't stand the LV list controls implementation...

Very good to know. So essentially the only time the unlock fails is if the lock has previously failed (with the same error). Thanks for clarifying. I find this statement however implies behavior I'd not expect from LabVIEW...are you implying that in this case, if auto handling is enabled and you have an unwired error terminal on an IPE node whose mated side *is* wired, LV won't automagically halt execution when an error is generated? Does this apply for variants as well as DVR nodes?