Mr Mike

According to this thread, OpenG has zip reading and writing functions. You can find them here.

Maybe. If process A and B check for sharedfile.lock at the same time and it doesn't exist, both will try to create the file and one will fail (one will create it first, the other will try to create it and fine there's already a lock file). In this case, the failed one should go back to step 1. I think your best bet is to use the locking that you seem to be encountering to your advantage: if you try to open the file and it fails, try again until it doesn't fail. Yes, it's a frequent problem. In the same application, there are a number of tools you can use to ensure safe use of a shared resource. Outside, it's a lot harder. (Typically the resource itself will be responsible for that: e.g. twitter displays the fail whale often) Yes, and it's hard (or maybe impossible?) to create your own lock with a separate file because of the timing issue I discussed above. Basically any time there is more than one step to open and lock a resource there's the potential for a race condition like the one we're talking about here. As far as I know, the answers are maybe and no. Check out Deny Access in the File I/O -> Advanced palette. I've never used it, but it may do file locking? Maybe? Play around with it and see if it gets you what you need.

The issue that you may have run into was file locking. I don't know what LabVIEW does in terms of file locking on Unix-based systems. The text utilities you used were probably no more immune to it than anything else, it just happened that you didn't run into problems with them. I don't know of an industry standard way of having two processes access the same file (other than try not to do it). I'd say your best bet is to just keep trying for a few seconds until the file is openable, but someone else might have a better suggestion.

I think what you're describing is opening files for write. I'm 99.99% sure LabVIEW 7.0 can do this. Place an Open/Create//Replace File node on your diagram (in the File I/O palette). The third input on the left should be an access specifier: read/write, read-only, write-only. However, the overall problem you're describing is a race condition. Race conditions are bad. Newer versions of LabVIEW (I've only recently used 2009 and above) have network variables, which would probably work for you and immune to race conditions in the situation you're describing*. It allows you to transmit data between two applications on a network. *You can still create a race condition with network variables, but if one is only reading the data and one is only writing the data, there's nothing to worry about.

kugr, I'm not sure I follow your post entirely. However, an integral part of the fix for that CAR in 2010 SP1 requires you to recompile any VIs that use class property nodes. Deleting and replacing the property nodes would have caused it to recompile. If you can still reproduce the issue, please post your exact steps. I'm sorry that my features caused you so much frustration. Me right now -->

You can append a random variable to the URL. But first a quick primer on URLs: "http://" is the protocol "www.example.com" is the host name (the computer the web page is on) "/some/place.html" is the path "?random=SomeRandomValue" is the query string The query string is a question mark (?) followed by a set of "variable=value"s, separated by ampersands (&). So if your URL is http://www.a.com/b.html you could make it http://www.a.com/b.html?rand=1234. If your original URL already had a query string (e.g. http://www.a.com/b.html?a=1) then you'd use http://www.a.com/b.h...?a=1&rand=1234. That will force the page to reload because the browser recognizes that could be a different page.. Just remember to use a different random each time. That's a common problem in a number of programming situations not just limited to LabVIEW. The HTTP protocol has metadata saying how long to keep a cached copy around and also metadata to say if a file is newer than another copy. I'm not sure if your web server isn't sending that data, it's sending the wrong data, or LabVIEW isn't respecting that.

No, there's no way to do that. Since my last post, I found this thread, which documents that this is intended behavior and if we want to use the drag/drop events, we need to do the move ourselves

NI employees know no barriers! I should have been clearer in my orignal post: my inbox was filled with emails from coworkers saying they'd be working from home today

Method 1. Make it snow. The attached picture is actually from last year when it snowed in Austin. It snowed last night (a whopping 3/4"). I'd put up a new picture, but there's nothing to take a picture of since the office is pretty much empty! Do you have any other strange ways a competitor might try to take out NI?

This is now CAR 280980. I aim to fix it in the next version of LabVIEW (not 2010 SP1 ). The current solution we're considering is allowing overriding properties to have different long names, but to always show the name from the base class. Suppose you have the following code: vi.lib/someClass.lvclass (English LV) - [Property] One (Long Name = One) - Read One.vi - Write One.vivi.lib/someClass.lvclass (French LV) - [Property] One (Long Name = Un) *** LOCALIZED *** - Read One.vi - Write One.viCustomerCode/Child.lvclass (derives from vi.lib/someClass.lvclass; based on English LV) - [Property] One (Long Name = One) - Read One.vi (overrides Read One.vi in vi.ib/someClass.lvclass) If I'm a customer and I ship my Child.lvclass to a French LV user, in 2010 my Child.lvclass will be broken because the long name is different. When this CAR is fixed Child.lvclass won't be broken, but any use of its One property in English LabVIEW will show as "One" and as "Un" in French LabVIEW. Solution: get the long name from the parent class and allow classes to give a different long name.

I've just posted the beginnings of a LV project to make barcodes in LabVIEW over at the NI Developer Community. It's currently in beta (used loosely: I wouldn't want to imply that I'll finish it ). Let me know if you have any feedback. Thanks

That sounds like another one of the symptoms of the CAR Jon Kokott found (248637). Please let me know (private message is fine) if you are able to reliably reproduce it.

Tomi, This is the expected behavior. Suppose there were static properties that you wanted to localize. You couldn't do that by overriding. Furthermore, an override should provide a different behavior, not a different name. If someone wants to create a localized version of a class they cannot modify, they should wrap the class and any parent classes that have methods/properties that need to localized too.

The Long Name can be set in the editor by going to the class properties dialog (i.e. right clicking on the class and selecting "Properites"), selecting "Item Settings" and choosing the property you want to edit. The same for the Short Name. The long name must be the same. This is because the properties in the property selection menu (i.e. the menu you get when you click a property node) are populated based on the long names from the property node's class and all parent classes. If we changed the name in the menu, it would appear you're using a different property. If we didn't change the long name in the menu, then the end user wouldn't get what the developer intended. So, you can't override and specify a different long name. The same should probably apply for the short name, but it isn't. (That's probably an oversight on our part, but it'd be incredibly hard to change since we've allowed it, we don't want to break existing code.). In any case, the short name of the child (overriding) class is used. The long name must be unique. You will get an error message if you do it in the editor or an error on the error wire if you do it via scripting. If you do it with a text editor, then when you open the class the VIs in the property definition folders with conflicting long names will be broken with an error message explaining what's wrong. You need to copy the class file and set the localized names on it (using LabVIEW, a text editor, or scripting), then ship the localized class file with your localized product.

Believe it or not, there are four names. All are exposed via scripting; three are exposed in the editor. Here's a first second draft of something I typed for a KB: There are a lot of names associated with LabVIEW Class Properties. There are four actually. You can access them all using an LVClassPropDefFolder reference (which is a ProjectItem reference). There are three that all properties in LabVIEW have -- two you may recognize and one you probably won't. Long Name . The long name is what shows in the property selection menu (when you click on an item in the property node). This name is also used to structure that menu. If there is a colon in the long name, you'll get a submenu ("pull-right"). e.g.: If you had two properties with long names "Color:Foreground" and "Color:Background," they would both be in a "Color" menu listed as "Foreground" and "Background." You can show long names in the property node by right clicking on it, and selecting "Name Format » Long Name." The Long Name can be set in the editor by going to the class properties dialog (i.e. right clicking on the class and selecting "Properites"), selecting "Item Settings" and choosing the property you want to edit. Long Name is readable and writable. Long Name will be matched when using the SetProperty method on a PropertyItem reference if you set AllowAlternateNames? to True. The Long Name can be localized without having to change code using the property. Short Name . The short name is what shows in the property node by default. This is readable and writable, too. Within NI, we generally make the short name an abbreviated version of the long name, but using periods instead of colons. Other than that it has the same behavior and uses as the Long Name. Data Name (Also called UniqueDataName). A (not quite) internal representation of the property name, but useful for scripting. When you use the SetProperty method of scripting, it takes in an IDString. The Data Name is that ID string. The Data Name is unique within the class and is read only. The data name is the names of all the folders in the class leading to that property definition folder separated by colons. e.g. If you have the following class, the data name for the property definition folder "d" will be "a:b:c:d". C.lvclass+-...+-a (Folder) +-b (Folder) +-c (Folder) +-d (Property Definition Folder) +- Read d.vi Name . The Name property actually comes from ProjectItem, the parent type of LVClassPropDefFolder. This is the name that shows on the folder in the project window. When you update this name, it'll update the short name if and only if they're the same and it'll update the long name if and only if they're the same. To ensure that the Data Name is unique, the Name cannot have a colon in it. None of the parent folders of a property definition folder (a, b, and c in the example above) can have colons in their names either. I hope that sufficiently explains the names associated with a property node. Let me know if you need more information.

That sounds like the same problem and it should be addressed in 2011 (as always without making any promises). If you can reproduce it and describe the steps, I can probably tell you. If you can reproduce it but not figure out the steps exactly, try recording it with Jing. However, I should say that including my fix for CAR 248637, I don't know of any case in which a property item will black out other than if the property name changes AND the file name of the accessor VI changes.

Yes, that's where the CAR should appear. I don't know how long it will take though.

Could you describe problems with DVRs? In the examples you sent Lynn, I don't remember seeing any DVRs. Looks like I'm going to have to eat my words on that one. It turned out to be a property nodes related issue. I have a fix for the issue and I'll try to get it in the next possible release, which may or may not be a bug fix (SP1 or 2011). I can't promise anything. (On a side note, I wish there were an embarrassed smiley that wasn't holding a giant "Oops" sign) You may also see this in the Known Issues List as CAR 246263, since that one is the same issue and was just about to go on the list. Sorry you couldn't use my feature for your project. I hope you'll try it again when the fix comes out.

There are two reasons a property item may be broken (turn black): The property you're trying to access is inaccessible (scoping). We originally thought about not letting you select that property item, but that went against our approach of letting the user do what they want in the order they want. If they wanted to use a private/protected property out of scope and they decided to make it more available, they should be able to access it and then change the scope The property you're trying to access can't be found. This can happen if you remove a property or change its name without the property in memory. See my first response to mje on another reason it may happen If this is the problem that I think you're describing, I've got a fix which is still being reviewed. (The person doing the code review has been out sick for a few days). The basics of that problem is that behind the scenes the properties have different names for if it's dynamic and static and some property nodes weren't getting updated when you change the properties from dynamic to static or static to dynamic. The problem only happens when you change the class input before you change the class output. This is CAR 248637 if you're interested. I haven't heard of any problems with DVRs and property nodes. What specifically are you having trouble with? Jon Kokott's issue appears to be caused by something not related to property nodes, but the property nodes are just getting caught in the crossfire. I haven't had time to take a good look at Jon's demo (I just heard about the issue before I left last night), so I can't say for sure why it's happening. It might help to force a compile (Ctrl+Click the run arrow) after loading a VI (i.e. opening or restoring). I recognize this isn't a solution for a lot of cases.

Hi Jon, Sorry to hear LabVIEW Class Properties aren't working for you. I went ahead and got a copy of a project that an Applications Engineer (Lynn) had made that demonstrated the problem. It looks like another bug that I had seen but couldn't reproduce. This sounds to be a lot easier to reproduce, so it should be a lot easier (comparatively ) to debug. When I get a chance to investigate it more thoroughly, I'll post here / communicate with support. - Mike

Djed is correct on both counts: property nodes by value are decomposed into standard method calls (with some error handling code to mimic property node error handling behavior). DVRs to classes have the same decomposition but the decomposed code is then placed inside an in place element structure. The error out on the DVR read on the IPES border is merged with the error input to the property node. The errors are passed into a merge errors node. You can see how it works in the image below. - Mike P.S. I'm glad you like the feature

These are two separate issues: drag over not working, and drop deleting tree items. You can use the attached VI to copy a tree and event structure out of. What's important is that you have the old event ("Drop?", not "Drop"). You can replace the tree with a system tree as long as you right click on the tree and select Replace. Don't delete the tree. TreeWithDropEvent.vi