ShaunR

Yes. It supports 2009 x32 & x64

That means it has only been assigned a generic class. If you right click on a control (for example) and "select IVI class" then it will return that class you choose.

There's a couple of property nodes TypeClass and SubTypeClass which will give you the class names. Is that what you are after?

It's bundled as part if the Vision Acquisition Software

Website is back so, so read the page. From what I could see, the OP must have already done that as it is working. I'm ot not really sure if x-domain is relevant to that anyway. All the XMLHTTPRequest would be doing is sending a "GET" to the server on the same domain as the page was served (just as if the page was refreshed....but without refreshing it). It's not as if it would be opening an 3rd party site in an IFRAME (which is where you get problems). I'd be interested to learn what problems you encountered and (probably more importantly) what you did to get round it.

Probably not..lol. I don't have much experience with streaming from the NI webserver (for example). I prefer other methods like TCPIP or websockets for that - they don't have such issues and (IMHO) offer better performance. But for normal HTTP requests (on the server side) it can be as simple as a PHP script on the corporate server that uses cURL to resend the request to the NI server and relay it back to the browser (easier than trying to get proxies and stuff authorised and set up by IT). As such, the corporate server is indistinguishable from a browser as far as the NI web server is concerned (and if you want , you can do caching and stuff too). It keeps IT happy since their portal is still the entry point and secure behind their firewalls and security policies, It obviously has an impact on performance - but it's not much for get/post methods through an Intranet, It also makes aggregation of multiple LabVIEW machines a breeze. It's one of the few scenarios where IT are actually useful

I cannot read that document at the moment - NI down again (might have read it in the past though). But from experience, most uses of the NI web server are to make VIs available internally within a company (managers and engineers looking at production etc - Intranet). therefore x-server really isn't an issue. When/if external access is required, usually IT insist that any requests are routed through their main servers anyway, so the browser requests it from a page on the corporate site and the request to the NI web server is sent from the corporate site. So the content seem to come from the same (corporate site) domain as far as the web browser is concerned..

+1 on can't upload. Couldn't upload a VI (64K) and a snippet. Just said "the upload failed". (Tried in Chrome, IE and firefox-no dice).

Making excellent use of LabVIEWs x-platform capabilities then

Easier than you might think. Just attach the updateData to a button Onclick event.

Make JG Dance For You Windmill and kick is my favourite

It depends on what you mean by "merged". I use named queues rather than a named types which means that (amongst other things) I can send a string across the network and dynamically create a queue with that name at the other end.. I can't think of a way (off the top of my head) that I could easily do that with events. But generally. I think queues are easier to use since you just grab a reference by the name from any module without having to run wires or store the ref in a globally accessible storage. But apart from that. Yup. they are pretty similar (maybe because events use a queue?). Interesting to note that there is about 20% a difference in performance though (although I haven't looked closely at the test method)..

Are using the "Base Package"?

IC. The conditional disable will give you the bitness of Labview you are using. For the OS you can use the OS.Name property node.

The "Conditional disable" has pre-defined conditions for different OSs (bitness is one of them).

When you manipulate an integer it is always based from bit 0 i.e integer 1 = 00000001 (2^8 = 256 possible addresses). But that bit (LSB , bit 0)is used as a read/write flag. So Address 1 = 00000010 (integer 2 for a read) or 00000011 (Integer 3 for a write). Therefore the address is shifted by 1 bit and you are only using the top 7 bits (2^7 = 128 possible addresses) You can then OR your read/write flag into bit 0. If you were to send a U8 with the value of 1, you would in fact saying "write to Address 0". Sending. Integer 2 would be "read from address 1". and Integer 3 would be "write to address 1 etc. U8 (0) = 0000000 0 = read from address 0 U8 (1) = 0000000 1 = write to address 0 U8 (2) = 0000001 0 = read from address 1 U9 (3) = 0000001 1 = write to address 1

I think warnings are a double edged sword. For example. How many people turn off warnings on the LabVIEW error dialogue unless you are optimising? I prefer prioritised errors since the default Labview handling for errors will pop-up dialogues which then forces you to consider the seriousness of the error. It also enables you to do things like graceful degradation. Warnings, however, don't really give you much apart from the headache of documentation explaining what it means..

I wish I could find stuff on LAVA. I've commented many time before..but here we go again. Windows indexing is the windows search service (so no, you can't turn it off in LabVIEW AFAIK). It periodically runs through the system acquiring locks on files, reading its contents (so you can search contents), and building up it's quick search database. I've been bitten many times in the past by getting file errors at seemingly random intervals and it's a killer on logging apps. I now routinely disable it and have not been bitten by random file errors since (only my own faux pas - but I can debug those ) How to turn it off Try turning it off and see if your problem goes away.

If you are running under windows, turn off windows ndexing.

From my experience it's not so much the size of the file. It's the size of the hierarchy. If you have 1 VI that is 44MB it will load a lot faster than 10,000 VIs @44MB. Although I would want to debug the former . A splash screen means that you only have a very small hierarchy to load before you can display something. It also gives you the opportunity to "incrementally" load you application For example, you may have a "hardware check". In running that, you have loaded quite a few VIs that you probably use in the main app (and done something useful) without having to wait for the whole app to load.

Well. It's the same as the image ....but

If it's your dialogue. Why not just bypass it completely or put a switch in to disable dialogues (maybe log it to a file instead). If it's not your dialogue (i.e in another application) then there are some suggestions here.

Like this?

Probably is if you are talking to architects and experienced clds. But "most" labview programmers aren't and the limit of IPC conversations tends to go as far as a producer consumer loop with queues and that's about it.. I've yet to see a student, electrical or electronics engineer (LabVIEW is still seen as a secondary skill in many companies eyes) talk about IPC and messaging systems. And I've worked, and interviewed many. And those are exactly the apps that can fall fowl of this "feature". I've commented many times about how I feel that events have been neglected. So you are preaching to he the converted here. Well. Actually, in the strictest sense, Events shouldn't have a timeout at all. An event is either signalled or is not not. No other language I know of has event time-outs and if a programmer wants to time-out if no event is received within a time-frame, then he has to create a timer that gets reset when an event fires. This is probably why the event case is as it is. The windows forms message callback (Wndproc) just has a timer that gets kicked on entry. As for not registering unless you need to react. that is only applicable at design time. What if you have configurable alarms? You will still need all the cases on the off-chance that a user will want to register it and receive feedback. thats one of the more useful (but rarely seen in LabVIEW) uses for events. Unfortunately, I don't think it is "cool". At best it's unexpected behaviour and explains (IMO) a lot about problems people have seen with xControls.

I would actually categorise it as "unexpected behaviour". If it is a bug or not then depends on whether it was specifically designed to not timeout under certain circumstances. My guess is it wasn't considered and "most" developers would want a time-out to, well, time-out I think it's probably because most people only use the event case for the UI (and generally wire -1 to it). And only a few are brave enough to base a whole inter-process messaging system purely on events.So if anyone is going to find it....it's you