Mr Mike

I have permission from AQ to say this: Aristos Queue has no idea what he's talking about. It's possible to deprecate properties, but we have it hidden. This was built so some of our APIs could be deprecated with the potential of releasing it in the future. When you deprecate a LabVIEW Class Property it will remove the item from the property menu and is supposed to turn the property node reddish pink (it doesn't because of a bug I just discovered). I don't remember the behavior of deprecated overridden properties. The deprecation applies to the LabVIEW Class Property Definition Folder itself (i.e. the property itself), not the individual methods. I'm not against turning it on in the future, but I think it'd need to have significant public support before I get off my lazy butt it gets approved. Uhhhhh...you mean like this? Seriously, this is what it looks like if you know how to show it.

I made a list recently of nodes that ought to accept/output an array of bytes instead of strings: Flatten to String (should be to bytes) and unflatten, FTP, TCP, Bluetooth, IrDA, VISA, String to Byte Array, and Byte Array to String There are a lot of other nodes that need to be changed to accept an encoding input, handle encodings in them (like the HTTP VIs). But the important thing, as mje pointed out, is that it is broken less than ideal. Want to write an app to help you learn Kanji? What about one that supports Hebrew? And Arabic? What about an app that loads Greek data files? All of these can be done, but require an intense amount of research and development into encodings that you shouldn't need to know, some unsupported INI tokens, and potentially changing the locale on your machine. Right now it's not a high priority, but it's something that we're mindful of. If we help our customers stop interchanging strings and data, that will help the LabVIEW community as a whole understand the differences between text and data.

I think this would be better if your tools took in an array of U8s. You're not sure if you encrypting data or text. Data should be represented as an array of bytes (U8s) and text should be represented as strings. In LabVIEW we've traditionally (read "incorrectly") treated an array of U8s the same as a string because the data types are essentially the same for our strings. We want to change this in the future and work away from treating strings as data, since you can only represent a small subset of characters as U8s. (For more information, see Text Encoding and Windows-1252. Windows-1252 is the character set / encoding that LabVIEW supports in English (and French and German, IIRC. Japanese, Chinese, and Korean are obviously different). At a very high level, the guidelines we came up with can be boiled down to three rules: Only use the string datatype for things that are actually sequences of characters. Use arrays of U8 for things that are arbitrary binary data. APIs that operate on strings should do what makes sense for a sequence of characters. APIs that can support either string or [u8] should provide separate entry points.

I can confirm the bad behavior mje's reporting. I didn't have all the icons that he has. I'll reopen CAR 185059.

I'm not seeing the Xs: I'm pretty sure the fix didn't require any action on your part. I noticed the package you attached here didn't include any palettes. I wonder what happens if you don't include the palette files. The CAR mentioned above (185059) included a palette in the example code.

Have you seen these: http://zone.ni.com/devzone/cda/epd/p/id/6401, http://www.soslabview.com.ar/en/aes-library-labview?

I don't have any official G projects through NI, but I've been working on a dialog to help sort LabVIEW Class Properties (they're sortable in 2011 through VI Server!), and extending my barcode generator to include 2D barcodes (right now just PDF417, since that's the only one I could find a free spec for). As for non-G projects...well, I can't really talk about those

If you have the old file that was causing the crash, please please please make sure you contact NI support and provide them with the file so that we can track down the problem.

Hello Neil. Sorry that you're having trouble with the speed of LV 2010. I'm not sure what the issue is (I haven't been tracking problems with 2010 other than the ones I wrote ), but you might be able to get help on the official LabVIEW forums, since we have customer support there. LAVA is just where some LabVIEW developers come to play. As to your question about LabVIEW Class Property Nodes. I'm glad you're using them and liking them. They shouldn't slow anything down at runtime because under the covers they behave just like a bunch of SubVI calls in a row. They shouldn't slow anything down at edit time because they act like regular properties on a property node. I haven't heard anything (good or bad) about the performance of LabVIEW Class Property Nodes, but if you discover they're slowing something down, please definitely let me / NI know.

As the first place finisher of the 2010 "Find Justin on the convention floor and pay him $30 before all the seats are gone" games (I got the last ticket), I strongly suggest you get a ticket in advance. It took a lot of coordination and phone calls to find / secure a ticket

Is anyone else hoping they'll shorten the name to just "LAVA Open Bar?" We don't need "G NI-Week" and "-B-Q"

Just bought my ticket

You need to recompile the VIs that have the property nodes on them. If you do Ctrl+Shift+Click Run on the top level VI, that should fix it, as long as there's nothing like a Open VI Reference and Run invoke node (i.e. Ctrl+Shift+Click Run will compile anything in memory).

On the accessor VIs or the VIs that used the property nodes? It's the VIs with the property nodes that need to be recompiled.

There is no 2010 SP2. We've had a few patches after SP1, but none that affect property nodes. Götz,did you make sure you recompiled your VIs after upgrading to 2010 SP1? Any VI which had the problem linked above in 2010 needs to be recompiled in 2010 SP1 to fix it. To be safe, you should recopmile any VI which called a dynamic dispatch property in 2010.

So, I just talked to someone who would know about LabVIEW's behavior on hyperthreaded machines. According to him the OS presents a single hyperthreaded core as two separate cores. This means that it should treat two threads on one core no differently than two threads on multiple cores. He did mention a performance issue that was discovered in LV 6 or 7 related to multicore environments, but that wouldn't turn up from growing an application. Have you tried using the profiling window? The oldest version I have access to (easy access, that is) is LV 5.1 and that has it (under Project -> Show Profile Window). In LV 7.1 it's under Tools -> Advanced -> Profile VIs...). You can see where your slowdowns are. - Mike Benza

I never noticed it kept that between runs! It works for me on 2010. The INI tokens are colorHistoryItemA through colorHistoryItemK. Do you see those in your INI file / do they change when you pick colors and close LabVIEW? I think when you select a color, that color gets put in K and then everything from K to B shifts to J to A.

Static and Dynamic refer to how the method is called. Suppose you have a Vehicle.lvclass and a Bicycle.lvclass, where Bicycle inherits from Vehicle. If you wanted to add a method on Vehicle.lvclass that behaved one way for Vehicle and another way for Bicycle, you would use a dynamic accessor. Suppose it was ChangeGears.vi.: Vehicle.lvclass --ChangeGears.vi Bicycle.lvclass --ChangeGears.vi You could pass a Vehicle wire into ChangeGears.vi, and if the actual type of the object on the wire were a Bicycle, it would call Bicycle.lvclass:ChangeGears.vi. If it were a Vehicle or any other class that inherits from Vehicle that doesn't override ChangeGears.vi, it would call the Vehicle.lvclass:ChangeGears.vi. Static means you cannot override the accessor, and you only get the behavior defined at the top-level class. This has been (perhaps better) answered here. You can change between static and dynamic by right clicking on the class in and class out in the connector pane and switching from Dynamic Dispatch to Required (for input) or Recommended (for output). - Mike

The method to get a VI's qualified name (given its path) will be considered for being made public in 2012. As for the other requests, I think an idea exchange idea is in order. I don't even know if it's feasible.

I'm a confused what you're asking for. Are you asking for the LabVIEW version of the class hierarchy, or the class version. (LabVIEW Version is easy to get from a library reference. Class version I think we'd need AQ to weigh in on). And just to be clear: are you asking to get this information from an object or from a class reference? I'm guessing you mean object. I guess the major hold up is converting an LV Object to a class reference. I'll ask about making the VI Path -> Qualified Name method (it's a method, not a property; I edited my original post) public in future versions. - Mike

That's an interesting problem. I don't think there's a way to get the qualified name from an object. You can get it from a class reference, and you can figure it out from a VI reference (concatenate its library's qualified name with a colon and the VI's filename. I think the qualified name of a clone is different though.), but I can't think of any way to get a class reference from a LabVIEW Object. (On a side note, there is a way to get a VI's qualified name given it's path. It's a private method that you need a special INI token to view. Does anyone think this would be useful?)

I'm not involved in any of the business decisions (such as pricing, bundling, etc). I was just curious about your reaction to LabVIEW Web UI Builder in general. I asked to have this thread split out of yours since I had unintentionally hijacked your thread. And you did a damned good job of proving it. Again, I don't have much say in the business side. I agree that NI ought to be further ahead in terms of internet technologies. However, one of the major hangups (in my opinion) is that you've got to use a graphical programming language to write out a text markup (HTML) which is then rendered as a graphical system (a web page). We want to cut out the text part (not because we hate text-based languages: if we did, we'd rewrite LabVIEW in LabVIEW ) because that transition (text to graphical) limits by nature and by design how your data is represented and displayed. Your text is put in a box that you can control a lot of the appearance of, but very little of the behavior of. As a front-end display, that actually fits pretty well. As a front-end control panel it would hold up for basic usage, but I think it wouldn't work for very long without an incredible investment in the controls and protocols. I doubt we could produce an interactive front end in javascript / html[5] that was half as responsive as a plugin-type system (.NET). Of course if it's just a basic front-end that doesn't need a lot of interaction, that's a great option. I agree we need SVG support. We have an internal tool which would vastly benefit from SVG support. It kinda makes me cry that there's no (easy) way to display an SVG file in LabVIEW. Though importing SVG for a control? I think there's more work there than we could tackle in one or two releases. Unfortunately, I don't think that's on the decision maker's radar. Right now, it's speed and stability. I don't use the Web Publishing Tool, so I can't really comment on that. I do want to let you know that I get what you're saying. I didn't reply to a lot of it because I don't have time to address every issue (or maybe it's because of super-secret NI plans, or I'm hungry and want to go home for dinner). Thank you for your feedback. I'm not about to go running to the business side saying we need to do these things, but I will (continue to) represent these views when the time arises.

I think the stuff you've put together looks pretty slick. Since I'm (nominally) on the Web UI Builder team, I'd like to get an idea of what else you don't like about Web UI Builder. So far, I've got this: It's only on Windows and Mac. It requires a plugin. Price (note: the price is for building apps for deploying; it's free for developing). Do you think that you should get free / discounted access to build/deploy apps after buying some other product / combination of products? (Note: I have absolutely nothing to do with the business side of things, so I don't have any input on pricing, bundles, etc. I can represent your feelings if I'm around when the discussion comes up) What else?

It's dynamic or static dispatch in disguise. If you set the object connector pane terminals to static (i.e. the class in is Required and class out is Recommended or Optional), then it will function as a normal subVI call. If you set them to Dynamic, then you'll have dynamic dispatch behavior. The overhead for a dynamic dispatch call isn't actually that high, so don't concern yourself too much with that. LabVIEW Class Properties are essentially syntactic sugar. They don't give you anything you couldn't do with subvis and case structures (for error handling).

These are both as intended. In all the object oriented languages I know child classes automatically inherit parent methods and properties. And yes, you can add code to a property node to make it have a side effect, but that's probably poor programming practice (alliteration for the win!) . The intent of being able to add your own code is to make properties for class members which don't exist. Suppose you had two pieces of class member data named "Number of Front Wheels" and "Number of Back Wheels." You wouldn't want a third called "Number of Wheels" because you'd need to update it when you updated either of the first two. You can create a "Number of Wheels" property which adds the two and returns the sum (in addition to properties for two members). You can also add code to add some sort of caching behavior. In general, LabVIEW Class properties work a lot like C# class properties.