Yair

There's still something I don't understand about your original example - when does the UI loop send the request for the updated data? Since we can assume the MC loop will handle it "instantly", the request can't be made a long time before you need it, because you want updated data, but it also can't be made too late, because that's exactly what you wanted to avoid, so how do you know when to send the request? Where would it fit into the code? It's easy to request the data when the code starts running or when you actually need the data, but I'm having a hard time imagining a piece of code that says "I know I'm going to need the position data 5 seconds from now, so I'm going to ask for it now", since code is generally not aware of upcoming events or states unless you would add a special "pre-check" event/state/whatever which will be responsible only for this.

Here's another question - in your example you wanted to have the updated position data, but if I understand your implementation correctly, the future is only updated once (when the MC loop processes the request), so if the UI loop only gets to process the response a minute later, it will get data which is a minute old instead of data which is current. Does that mean that this type of architecture can only be used where you're willing to accept that the response may be old?

Maybe I'm misunderstanding what you want, but isn't there also a fill to +Inf option where you set the fill to zero? Never mind, I see the thing about how you want it to be vertical.

I don't know what changed (if anything), but it seems to work fine now.

I'm with Wouter on this - just make the icon a bit wider. If you use François's trick, you will probably have problems with matching some of the wires, because they have a specific pattern and you would need to move the VI a couple of pixels this or that way to match it. Here's a very quick example: I think that this isn't too big and could probably be made better with a few minutes of polishing.

Try going for the de-facto standard - http://www.laputan.org/mud/

Don't get me started on right-to-left languages, as LV is currently woefully short of the mark in that department and just expanding support to multiple encodings will not be enough in that case, as you need to correctly handle cases where you have mixed R2L and L2R content.

Well, in any case, it looks like the OpenG version is considerably faster (I see ~20 ms for OpenG vs. ~300 ms for the vi.lib VI), so that answers that, at least.

Just to clarify, I meant adding the LV class value to the OpenG enum and then modifying Get TDEnum from Data__ogtk.vi along these lines: The alternative implementation might be faster, because it hopefully does not require flattening the variant.

Well, I would start with just recognizing that the variant is an LV class. From what I posted here, it seems I did find a way of finding out (although I don't remember what the code looks like). Alternatively, since OpenG is now in 2009, we can probably use the vi.lib variant VIs, which I assume do tell you if the variant is a class, so if it's a refnum, you call the vi.lib VI to get the actual type. Optionally, we could also ditch the entire type string code and simply use the vi.lib VI for everything and simply make a lookup table for all the existing OpenG types, but that might have performance and backward compatibility issues.

Admin Edit: The below series of four posts were moved from the Timestamp support for Format into String & Scan Variant From String (String Package) thread to here. On a somewhat related note, any chance of correctly recognizing LVOOP wires? Last I checked, they were recognized as refnums.

AQ, without thinking about it too closely, I believe that the suggestion I made earlier in the thread (use local wrappers around the primitives and call those wrappers using remote CBR calls) should handle those issues, as the execution is all done on local calls. I think the only problem you might have with that is if your connection drops in the middle of the CBR call, in which case the dequeue might happen, but you wouldn't get the data, but that's probably not something you can handle without writing a more serious network queue implementation (i.e. one which uses acknowledgments, but there you probably have the problem of where the ack chain stops). Sounds like an interesting problem.

Actually, I can confirm that the basic concept does apply in 2009 and probably in later versions as well. The reason for this is simple - LV needs to access the source code in order to compile it to machine code. Since the user can't be expected to provide the passwords (since, for instance, some of the VIs in the hierarchy were written by someone else) LV needs to be able to read the code even without the password. That means that the code itself can't be encrypted. Then, as Shaun mentioned, you get a place in the code where you need to check if the user's password matches the VI's password in order to show the BD and if you patch the LV executable to override that check - voila. In any case, it should be pointed out that other IDEs don't have password protection for source code, at least not as far as I know. I understand why NI put it there, but it should be clear that it's not something you can rely on if you expect to protect your code from someone determined.

The PRTC primitive does not cast a parent to a child. It takes an existing child which is traveling on a parent wire and outputs it as a child wire. If the data in the left input is NOT a child, the primitive should return an error (and, as you've seen, a default child).

Cross-post: http://forums.ni.com/t5/LabVIEW/Reference-loss-when-created-by-Dynamic-VI/m-p/1698122#M601558 It's considered polite to provide a link to the other thread if you cross-post.

OK, they suggested that you open an official support ticket, since this seems to be something which isn't easy to reproduce (when I created a new user it didn't seem to happen with that user).

Uh, it was actually even harder than that, because the string only had 1 byte, so I was sure the device wasn't sending anything back (why I was getting the first byte of a 1-byte string is irrelevant here, although there was an actual reason for this). Well, I guess that's what happens when you're asked to do something quickly.

I had something similar recently, when I wanted to get the first byte from a string: Unfortunately, I couldn't test this myself with the hardware, so I first found it after I remotely deployed it and found out something wasn't working. At first I didn't have debug data, so my initial reaction was to blame the hardware, which had both problematic documentation and a flaky history. Sigh.

Done - http://community.invisionpower.com/tracker/issue-32783-topics-are-still-marked-as-read-even-if-not-all-pages-are-viewed/

In case someone runs into this in the future, the property saver is here - http://www.kshif.com/lv/index.html

The division by pages may be arbitrary, but it still reflects whether I have or haven't read something. Part of the problem is also that the page links aren't prominent enough and it's easy to miss them. If the topic wouldn't be marked as read automatically, I would see it in the list even if I haven't noticed that there's another page. Personally, I would have liked it if the forums also had a feature which allowed you to mark a post as unread. The NI forums have this and I find it useful. Before I post this on their forums, I want to be sure we actually have the latest version. That's 3.2.0, right?

You can find the property saver here - http://www.kshif.com/lv/index.html There are methods called Get Property and Set Property which I believe should allow generic setting of properties. However, if memory serves, the require a 1D array of integers to identify the property (which you have no way of finding out) and I believe I remember someone from NI saying that they're not actually used anywhere, so they might be unsafe.

You can see some more about using the Externals keyword here - http://thinkinging.com/2008/10/21/set-the-revision-of-your-svnexternals-or-else/ I would agree that using VIPM is a lot simpler.

Basically, you need to create a new VI (with its type being control) and call the Save Instrument method on that VI. There's an example of this in this RCF plugin (although, if memory serves, that one doesn't save the VI) and a more complicated one here (which does save it).

According to the links you posted to the update notes last week (which I can't find at the moment), this issue was fixed in the new version. However, I just saw this happen with two threads using the exact repro steps which appear in the first post (in this specific case, these threads were the LAVA upgrade announcement and the OpenG in user.lib threads).