Yair

I believe you've misunderstood Rolf on this point.LV does not generate C code, but machine code. There are some exceptions (like LV embedded or (I think) the PDA module), but not the PC version. If I understand Rolf's explanation correctly, he meant that if you build your VI as a DLL instead of an EXE, LV will use the CVI RTE to generate parts of the DLL. At no time is the LV code translated to C.

Don't try to dodge your accountability! You've sown the seed!Anyway, I guess this admission will get me thrown out of the forums permanently, but - I don't drink beer, so it wouldn't work on me. There. I've said it. Now you can have your way with me. Didn't work last time...Maybe we should invoke Godwyn's law so the thread is closed...

Noooo..... hat are you talking about? It looks great! No one will stone you! You should do it! People will love it! Really... BTW, it seems the forum itself really didn't like your change of the avatar - Oh, and it's no trouble - takes about a minute with Imageready.

Who said it can't?

Although, if there are new errors for 8, that enum won't include them.

Define your errors in advance and make sure the code knows what to do when encountering each error. Make sure to have unique error numbers. You can try looking at the error handling section here for an article and some VIs.

If you still need to do serial communication, there are serial VIs for the PDA module (old style serial, no VISA). I don't remember using them, but they should presumably be in the Instrument I/O palette.

Then just do something like the attached example. I copied the image from Word and used it to replace the frame of a string indicator. The balloon even appears near your control.Download File:post-1431-1149069054.vi

I believe this should answer your question. Reminds me that I actually need to properly get into this myself one of these days.

As an addition to emulating the windows explorer behavior, if you're using the Key Down event, you should consider using the Key Down? event instead and discarding all the clicks for the illegal characters.

As Neville pointed out, the student edition is basically identical to the FDS, but one other thing which is rather annoying about it is that every front panel will always have the watermark of the student edition. If you're working with a large enough resolution this should hopefully not bother you too much. The wireless stuff can be implemented through the Bluetooth or TCP functions (I recommend the TCP over Wi-Fi) and it is extremely easy in LV. You should consider the fact that if you are completely new to LV you might have trouble producing a complex application - LV is much simpler to learn and use than other languages, but it's paradigm is somewhat different, and to produce quality results in complex systems requires some experience. P.S. Stay away from the base version (the $1,000 one). It lacks some important stuff (like the ability to configure event structures).

Pay attention, this is complicated. Open the Example Finder (Help>>Find Examples). Go to the search tab. Search for "Excel". Open the example which shows how to do what you want. Run it.

An approach that immediately comes to mind is using the picture control - you will need to recognize the number of unique elements and how many connections each one has and decide where in the picture you want to display each one. Drawing the arrows is a joke (just create a subVI which recieves the start point and end point and adds the arrow head based on the angle) and writing text is not a real problem (you can easily create another subVI which will even write the text in a filled circle or rectangle), so the main challenge should be the code which decides where to put each element.

Maybe I should have thrown "I'm MELTIIIING" in there as well. I think that to see why this was nominated here you have to actually open the VI (although it is true that the description also shows that the VI is far from being generalized enough).

Ow!!! My eyes are completely burned now. I can't see! I CAN'T SEE!

I thought the point was to get rid of the subVIs. Rolf will probably jump in soon enough to tell you that integrating a C compiler into LV is something that would be a huge undertaking and not worth it because that's exactly what LV is not (and you should always listen to Rolf). When he will tell you this he will probably also say that if you're already content to write this in C, you might as well use a real compiler and build the DLL.Isn't it nice that time is bidirectional and I can tell what will happen in the future?

I haven't played much with dynamic code generation, but as far as I know this is more complex than copying and pasting - you have to select only functions and wires (not terminals) and then you have to replace the existing code and link the pasted code to the appropiate place. As far as I remember wires don't appear properly in the Objects[] property and so probably need to be handled seperately. Also, this will probably make your code really ugly (although if this is only for execution this should matter less). The other thing I would be afraid of is the reliability of thing - you wouldn't want your code to be messed up because the programmer overlooked something or because a scripting feature wasn't fully developed. If it's that important, it's probably better to do it manually or to write it in a single VI in the first place.

Can you create a specific example showing whatever you think the problem is? I remember testing the remote FP methods and properties in 7.0 and they worked fine. I assume they were tested for 8 as well.

Looks like you should post to this thread to show that being a CLA does not automatically mean you get a job.

You need to be a premium member. Just follow the link in Chris's signature.

Another thing, since you're working with multiple LV versions - I don't know about DAQmx, but at least for FieldPoint, the FP Driver installed on your development machine with 8.0 (FP 5.0) takes the place of the older FP driver and can not work with LV 6.1 and below. So, if you have LV 6.1 and you install 8.0, you will find that you can't use FP with your old LV version anymore. Just something you might want to watch out for, in case there is a DAQ equivalent or if you're using FP.

And the OpenG file toolkit includes something along the same lines (saving anything (and everything)to an INI file).

I haven't done any LV<->Java communication, but using the LV TCP functions is simple and you can find several examples in the example finder (Help>Find Examples). Basically, you get a byte stream which is represented as a string. Normally, in the LV implementation, the sender calculates the size of the data and sends a 4 byte string (an I32) which tells the reciever exactly how much data it's going to get. That way, you can always read 4 bytes to get the size of the data and then ask for that size. You can do a similar implementation in your code, where you would (for example) always send x ASCII characters representing the length of the data. You can convert the string to a U8 array using one of the functions from the string palette and (if necessary) you can reverse the endianess of the bytes by using the VIs in the Advanced palette. I would advise that you stick to sending simple ASCII characters and not try to format more complex data into something that LV will understand.

Don't forget that RK has the most important certification of them all - he's a Knight of NI .

That's the problem with humor, you never know who you're going to insult. Anyway, not having used most features of the DSC module (except for mainly the image navigator and the IA OPC server) I'm not one to pass (or not pass) judgement on it.