Yair

You're probably refering to the DSC module, which would definitely add unnecessary overhead and would probably even be slower. A couple of ways of communicating between executables would be using TCP (but you should note that this won't be as transparent as DS or the SV) and loading them into the same data space (although that would mean you would have to be careful about doing this. For TCP, you can search the example finder, and for the other option, you can see for example this thread.

The way I understand it, they do not provide protection. Loading into the same memory space also means that you load into the same name space. But I guess you will have to try it to be sure. In any case, I didn't really understand your method of communicating between executables, but I don't think that VI name collisions would cause it to fail (at least not while you're in the same RTE instance). If the VIs are the same (which I assume they are), then all you will need is for the references to be valid, and that should be handled by loading the EXEs into the same RTE instance.

I find it surprising that the server would send other data on your connection. Normally, a server can talk to many clients by creating a seperate "channel" for each client. If that's the case, then all you need to (presumably) is display the data to the user. In any case, I would expect that there should be some way of knowing either the length or the end of the message. In your other post you mentioned this is a chat server. How do other clients know when the messages are over? Also, do you have the protocol the messages are sent in and did you look at the traffic to see if you can identify either a length or a termination char?

BTW, Michael, since you like those girls so much, you would probably like this version of their rendition of Barbie Girl. Since it doesn't have sound, you won't even have to hear to the song . It's very funny to see it sync'ed to the original.

Did you try the method in my link? Once you do that, you can run the executable independently or using System Exec and it will be loaded into the same RTE instance as the other executable. Then, they should be able to share everything. Just note the warnings given by Damien Gray.

That depends on how your server works. I assume you can't control it, so what you will need to do is one of the following. The first solution would be to ask for a large number of bytes (larger than the longest message you can get) and set a long enough timeout, but you say this won't work because the server sends additional data. In that case, you will need to know what you're getting from the server. Either you will need to know when you send the command in what format the server will send the answer (and then you ask for a different number of bytes each time) or you will need to be able to recognize the end of the answer and then you ask for a single byte each time until you can identify that you got the message correctly. Of course, if the server sends the length of the data in advance (as is common in LV implementations) then all you need to is read that part of the answer and then you will know how much to read. Note that in any case you will probably need to handle error 56 seperately for the loop because it will have different meanings depending on what you're doing.

That's really not bad. I need to remember to check those guys out.Of course, if you get bored, you can always go for some SOAD. The guy in the front is great. Not to mention that the original is an excellent video too. P.S. So how do you embed those? I tried copying the HTML from Google and playing with the HTML options here, but couldn't get it. Or do you need to be a premium member?

Well, just follow the link and you should see that Ben is probably right.

What I found funny was how much of the lyrics I actually remembered (most of them, with exact timing). Hmm... Perhaps webcams weren't such a good idea after all. P.S. Before you start making fun of me, I may like this song enough to remember its lyrics after a few years, but I wasn't the one who spent an hour listening to it repeatedly. :laugh:

The US not having a lot of cell phones and having most of them CDMA are good points for why NI might not have done this so far. Even if other countries have more phones and GSM, I believe that NI puts most of its effort into the US, and I don't know if they'll create a whole product which can only be sold outside the US.I don't know wether the appropriate hardware will "become available", but if Symbian devices have support for USB and/or CF, I believe that should be enough on the device side (obviously, you will need drivers). Last thing - while it is definitely costly to port and support the runtime engine, in this case it's irrelevant since LV PDA does not have a runtime. Instead, it translates your code into C (or C++, whatever) and uses eVC to compile it. That's the source of all the bugs in the PDA module and there probably are differences between the platforms which require making changes to the C code as it is generated. That, and considering that stuff that is installed (like the newly added VISA support) would need to be ported, would make this costly.

To be honest, I'm not very big on any of the hand-held devices market and I've never used a phone with Symbian, so it's quite possible my terms were just wrong. If the device has enough power\memory and the proper hardware support (CF\USB) to run "LV Programs" and support NI hardware then I believe NI would support it if they thought they could sell enough to cover their investment. I don't know how many of those phones would qualify for that. The main advantage in WM for NI, I suspect, is that it has Windows compatibility and that it is easy to compile the C code that LV creates with the PDA module using eVC (although Symbian probably has tools for that as well). The DaqMX base and VISA implementations probably also had to go relatively minor changes in order to be adapted for WM. I don't know how many Symbian devices have support for BT/WiFi/CF etc. and the power to run LV programs, but I believe all WM based devices should be able to do that, so that's probably another advantage. As I said, since I don't know Symbian, it's possible that all this wrong, since much of it is only guessing anyway.

OK, I've looked at the Symbian site and it seems that most of the devices there are cell phones, not PDAs or smartphones. You should consider that LV has limited areas where it has advantages over other languages you can use for PDAs and phones - basically, it's easier to use and it allows you to connect to NI hardware easily. When you add to that the fact that NI does not go for the general applications market and that LV PDA is (warning, understatement ahead) far from perfect, you can see why NI would probably stick to a platform where it can possibly make money. I still don't see NI, in their current M.O., promoting LV as a language for general applications and I don't really see people running serious applications (the kind you use LV to write) on regular phones. In any case, I'm pretty sure NI didn't make too much money out of the PDA module so far (I don't think many people bought it), and I doubt they will throw more money in for additional platforms.

Are you calling the exe using System Exec or are you calling the top level directly? Is this what you're doing? If not, it might help you.

There's the key to the answer - "a number of applications" is simply not worth it for NI to spend time on this. I know that's not what you meant by this sentence, but the point is that NI would only support platforms where it will be able to sell enough copies to cover its investments and make profit. Palm (at least at the moment) apparently doesn't qualify, since they discontinued support, and I suspect that Symbian wouldn't qualify any more than Palm.I will say though that I have no knowledge of NI's plans, nor of how large the Symbian share of the smart phone market is, but in any case, it's likely that as long as NI has the Windows Mobile platform supported, it would probably be more cost effective for both NI and the users to have the users buy a WM smart phone or a WM cellular PDA than to have NI put efforts into supporting another platform.

I have no idea what the release date for 8.2 is, but the quick start document does state that PalmOS is no longer supported.

How about this? Not a right click option yet, but it has been a scripting method since at least 7.0. Unfortunately, Bsvingen only found out after going through all this.

Note that while the menu item doesn't need to be called "About LabVIEW", the license agreement for LV does require you to enter some text into your application's about dialog which says that you used LV to create it.

Yes, NI stopped supporting PalmOS. See here. I don't think you can use PDA 8.0 with LV 8.2, but that's just an educated guess.

I never actually noticed this before because I usually remove the toolbar (naturally) and because I don't normally use the mouse leave event. In this case, the test VI I was refering to was the one from the coding challenge, which has both the toolbar and the menu bar visible and where I did monitor a sequence of mouse down/up/move/leave events. I would expect that if a certain area does not respond to mouse events, then it should trigger the mouse leave event. I wouldn't call this a bug, but I would call it an unwanted behavior. Any other opinions?

There is a simpler method, although it is a hack and as such unrecommended - you can use the Numeric Text>Text property from the numeric indicator.

I Believe Chris's attachment shows the key. The timestamp datatype apparently cannot contain and display a relative time, so it reverts to absolute time automatically (try setting the format to relative using the advanced mode and you'll see that it's invalid). Using a regular numeric indicator, however, should work.

Well, he is Greek, after all...Maybe "Motorcycle Accident" means something in Greek?

I'm surprised that no came up with "LV8.2-style global" yet (or "LV-eight-two global" as a shorter version). :laugh:

Oh...Well, so much for that edge...

Well, as part of our work with a local school we're apparently going to get some NXT toolkits. A local salesman came by this week and gave us a demo. There are apparently some differences between the home and educational kits, with the most significant I noticed being that the educational bricks have the option of talking to each other through BT. One nice video I've seen showing this has someone controlling a vehicle through a wireless joystick. Anyway, I hope will have some access (and time) to play with those kits when they get here and if anything nice comes out of it I'll be sure to upload it.