Leaderboard

None of those declarations are correct, and the errorIn and errorOut parameters are probably not optional - they're passed by reference and should be allocated properly. Passing a pointer to an incompatible data type will likely lead to problems. It will be difficult to get the errorIn and errorOut declarations correct in VisualBasic, though, because it would involve calling functions in the LabVIEW library to allocate an LStr and then creating a handle to it. ALL of the parameters, except color and len, are by reference (that's what the asterisk in front of them in the function prototype indicates). Further, as everyone else has explained, the ComPort parameter is a reference to a VISA session that is already open (specifically it's a pointer to an integer, where that integer value has meaning only as a reference to a particular session). Passing a constant that corresponds to the COM port you want to open WILL NOT WORK. You cannot call this function successfully without a prior call to open the session. If that function does not exist in the DLL, then you need to ask the DLL creator to add it for you. At the same time they should remove the errorIn and errorOut parameters, or at the least replace them with a data type that is more compatible with VisualBasic.

On thing you can do (although I haven't tested this with RT FIFOs) is create a type definition for the cluster that is the fixed-size array. Then, put that cluster inside the cluster that contains the integer. It is then easy to convert the nested cluster into an array (using cluster to array). Going the other direction is only slightly more complicated. If you know that the array size won't change, you can use array to cluster. Otherwise you can typecast the array to the cluster type definition; this may be less efficient (my understanding is that typecast will always flatten to a string, then unflatten to the new representation, instead of a more direct conversion) but is more flexible.

For the record, there's a truly fascinating design that I've seen implemented. 1. Make class Message Handler as a *by value* object. In other words, it has methods for "Handle Message X" and "Handle Message Y", and all of its data is within itself. 2. Put that class in a shift register of a message handling loop. Dequeue a message, figure out the type of the message, call the right method (how you figure out the message type -- strings, enums, dynamic dispatching, variants, finger in the wind -- doesn't matter). 3. Some messages tell the message handler to "change state". Let's say message X is such a message. In the "Handle Message X" method, instead of changing some internal variable, output an entirely new Message Handler object of a completely different Message Handler child class. That now goes around on the shift register. All future messages will dispatch to the new set of methods. Any relevant data from the old object must be copied/swapped into the new object. This eliminates the case structure in the message handling of "if I am this state, then do this action" entirely. Because we made the output terminal NOT be a dynamic dispatch output, you can implement this in the Actor Framework and switch out which Actor is in your loop while the actor is running. This is known in CS circles as the State Pattern.

Hi KJ, there's a board devoted to this on the NI forum, there you'll likely get a quicker turn-around on LAVA -- http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion -- good luck!