ShaunR

You also need to know the type ahead of time with the others as well (supply a control to define the type). I would prefer it just coerces to the type of the indicator that I hang off of it which in fact is more useful than the "To Data" and James would get his function without having to define the type input. It (i think) should behave like a polymorphic VI but we don't have to write all the cases. Until that happens. I'm still using strings and variants (to me) are still the feature that never was.. Can I also reiterate my long standing peeve about not being able to create "native" polymorphic controls/indicators. X controls is another "half" solution.

I still think this is a "half" solution. With variants, we should just be able to wire an output to an indicator and it should just do it without explicit conversion.

Users posting on a forum tend to have been trying for a while to get round a specific problem or lack of understanding. Muddying the waters with architecture (when not asked for) tends to just confuse and frustrate. I'm reminded of what a teacher once said to me for exam technique. Answer the the question, not what you think they are asking. I tend to solve the immediate problem (usually with an example) then suggest improvements. However. Rolf has a huge amount of experience in umpteen programming languages as well as solving comms problems on a day-to-day basis so his one-liner is second nature. It helps when they post an example as then you can tell their level of expertise. If they have roughly hacked an example shipped with LabVIEW and it "sort of works". They may have spent all day trying to get the last bit sorted. This generally means that they if you start spouting about OOP and Actor frameworks, then they will probably just give up as "LabVIEW is too hard to do simple things".

Depends how many dispatchers you have. If you have a single dispatcher (centralised server like a DNS server) then yes. If you have a dispatcher on every machine (like apache), then no-as long as you have reduntant processes elsewhere. The usual topology I use is to have a machine with, say, 5 processes and replicate that for failover. If the machine goes down then you just point to the other machine(s). That's the way the web works But haven't we discussed this before?

Yup. I meant the example to show dynamically launching of TCP processes (there are hidden "handlers" which are dynamically launched). I don't see any reason why it should be an issue. Launching dynamic VIs means you can run them in separate threads and/or execution systems from the launching process so although your dispatcher might be in the UI thread, the spawned processes need not be.

The LabVIEW UI has sucked for quite a long time now, but If your going to go for HTML and CSS you might as well take it completely out of LabVIEW and make it platform independent. Unfortunately, When it comes to artistic talent, I wasn't even in the building when they were handing it out So as much as I complain about the LV UI, I can't really do any better. The guys/gals that make those interfaces for the coding challenges just blow me away. Any UI in CSS, SVG and HTML that I do takes weeks and looks, at best, mediocre.

The server had a nervous breakdown because I got to the number 2 spot

This can be alleviated by using a camera with a shallow depth of field so that the hand is in sharp focus but a few inches back is totally out of focus. He will not be able to do that with a laptop cam however, but he might get away with a webcam with a manual focus ring if he is far enough away.

Depends on the drive. SATA 1.5 theoritical max is 150 MB/s, SATA 2 300MB/s and SATA 3 is 600MB/s. I have a NAS box at home that easily does a sustained 60MB/sec over a 1Gb connection (with Jumbo frames). NI PXI racks have pretty crappy hard drives as standard I would benchmark it with these http://zone.ni.com/devzone/cda/epd/p/id/5348 .....then buy a decent one

Are the HTTPS VIs that are shipped with LabVIEW 2010 and later not of any use?

Try using the "Mouse Leave" event of the pane? Although your last comment (tooltips display when it doesn't have focus) seems contradictory so that might not be what you are after.

Not really using it (in fact I hate the Metro interface so won't be upgrading anytime soon). However I needed to test out IE10 so put it in a VM

Not that fancy (it's LabVIEW doing the work ) I had a clear out not so long ago, so no. I don't. But I imagine it was something like this:

No. It doesn't matter. Only that it is an approved vendor (which NI must be otherwise they wouldn't be using LabVIEW). But lets not run before we can walk. Lets get it all working properly first. As I seem to be the only one that suffers from this, I will gradually replace the dependencies and you can decide whether you want to update the main trunk with the branch as and when it happens. I have to do it anyway, but you don't need to.

Indeed. In fact. I would let the individual segment downloaders save the pieces, then probably get the download VI to sew them all together in the right order before sending the file name back to the main app. As Asbo says. You don't need to send the actual data back. The segment downloaders only need to send the filename of the segment they downloaded and saved to the Download VI. I think this demonstrates it for you (quick and dirty though it is). Of course with these things there is little error checking and no limitation to the number of spawned sub-processes. But I think you'll get the idea.Some of your VIs were missing so I couldn't use those. But I made it download some URLs using the HTTP VIs instead. Exactly the same idea except instead of passing the HTML back, you will pass a filename.

Coffee, white, No sugar please

That's right (and I have never used any software from LavaG in a commercial application). However, it is much easier to gain approval for a single self contained API than it is for one that relies on another 20 (like the OpenG). The problem with the OpenG stuff is that you want one little VI and you have to get approval for 120. It's easier and quicker to write the bit you need yourself. And no. My re-use libraries are not a problem as I am an approved vendor.

That's the key, right there. You're only lacking encapsulation depth at the moment. The thing to remember about queues is that they are a "Many-To-One" paradigm. So you have Many segments to One file and Many Files to One Batch. I would tackle it this way......... Create a "Download File" VI (launched re-entrantly) which you pass all the segments (a list?) that are required for that file to. It, in turn, then launches the individual segment downloads (again re-entrantly) by iterating through the list. The last thing a segment download VI does just before it exits is to post the segment to the Download File vis queue (Which will be named something like Download File.vi:3 i.e the clone name). The "download File" vi receives all the segments (for that one file) and, when it has all of them, reports back to your main app. The main app just sits and waits for completed files to come in. In terms of queues, you only really need the return queues. So the Download File vi creates a queue to receive the segments (using it's clone name) and also has a queue named, say, "~download_files~" that is used to send back to the main app. All the download VI clones share the latter queue. The Download Files VI passes it's clone named queue to each of the segment queues (or you could get fancy and calculate it from the caller) so that they can use it to report back the individual segments to it's parent (the Download VI clone that launched them).

In theory. Practice and theory are the same. In practice, they are not Historically the openG stuff is generally more performant since a lot of them perform the same functions as are available in LV, just optimised. Of course with the NI grown ones they can have C functions in the exe to do the heavy lifting, but usually they use nodes that run the the UI thread which mitigates any performance gained Saying that. I use the vi.lib getTypeInfo,GetCluster/numeric etc but I haven't bench-marked them since they are "Hobsons Choice" for me.

I'm not opposed to that either but I thought Ton was talking about it going into the Lavag Tools Network.. Yeah. Well its got LVPOOP in it so that's not an option.

If you can wait until next weekend, I'll replace all the openG stuff so it's a self contained lib. Just a bit busy at the moment finalising the websocket demo, but that will be finished this week.

Get your IT department to handle all the internet stuff and inserted in a DB. Then just query the DB using the Database Toolkit. You won't have to worry about security, webservers and firewalls or have to maintain webpages, log-ins, registrations etc It will also be fully integrated with your corporate website. Your labview stuff will be safely isolated behind the corporate firewall.

Well. this is how it works at present. — the string “Hello” as a DBL? Is this NaN, zero, or an error? NaN (after all NAN= Not A Number) What about as an Int32? 0 A timestamp? Like I said. Odd one out since all the other LabVIEW "from Strings" have a default behavior defined (they don't return errors) — for that matter, what about a boolean? Should anything other than ‘true’/‘false' be an error? Any non-‘null'/non-‘false' be true (including the JSON strings “null” and false”)? Or any non ‘true' be false (even the JSON string “true”)? True/False, Yes/No, On/Off 0/>0 are catered for. anything else equates to False., — “1.2Hello” as a DBL? Is this 1.2 or an error? NAN — or just “1.2”, a JSON string, not a JSON numeric? Should we (as we are doing) allow this to be converted to 1.2? 1.2 These — a JSON Object as an Array of DBL? A “Not an array” error, or an array of all the Objects items converted to DBL? — a JSON Scalar as an Array of DBL? Error or a single element array? — a JSON Object as a DBL? Could return the first item, but Objects are unordered, so “first” is a bit problematic. These I see as purely internal representations (lazy typing-only define type when recovered) And what if the User asks for an item by name from: — an Object that doesn’t have that named item? Currently this is no error, but we have a “found” boolean output that is false. — an Array or Scalar? Could be an Error, or just return false for “found”. The default value and a warning? Then for the JSON to Variant function there is: — cluster item name not present in the JSON Object: an error or return the default value The default value and a warning? Personally, I think we should give as much “loose-typing” as possible, but I’m not sure where the line should be drawn for returning errors. I don't think any typing should be contained in the objects at all. Only interpreted when recovered to the best of our ability (as it does at present). Why enforce typing internally when there is none in the Json objects. Type is purely a convenience for wiring up to indicators/controls