Leaderboard

LabVIEW has no official support for right-to-left languages. I can say that it sort of works with Hebrew (in ASCII) if you know what you're doing, but I haven't tried with Arabic, so I don't know about connected letters. In any case, even when it does work, as soon as you add in anything which isn't part of the R2L set (such as a comma or a hyphen or a number), the display gets reversed. If you're on Windows, you can try using a .NET or ActiveX control and using the rich text box. That should display the text correctly.

I've posted information about a new help topic in LabVIEW 2012 about optimizing built application performance. Here's the link: http://forums.ni.com/t5/LabVIEW/Optimizing-built-application-performance-in-LV-2012-and-earlier/td-p/2121710. Greg Stoll LabVIEW R&D

OK, someone needs to start a thread on this new feature in LabVIEW 2010. Who has tried it and with what results? How does one work with packed project libraries most effectively? --- I considered this one of the more promising features of LabVIEW 2010, since we have large collections of reusable code that we realized we needed to put into project libraries. It would additionally be helpful indeed to build each piece only once (per change), which was the promise of the packed project libraries. The obvious application for us to try this on was one that took 40 minutes to build and consisted of a small application that talked to a large existing collection of code (in classes) used elsewhere. I assembled the reusable large portion into a library in one project and built it, included the referenced build in the calling project (OK, this was a nightmare--the lesson learned is to put your code properly into project libraries before attempting to reuse it!), and built the calling application. The build took... 40 minutes. Using packed project libraries didn't help at all as far as the build time goes. On the other hand, using packed project libraries does mean the dependencies of the called .lvlibp files are hidden in those libraries rather than in the top-level dependencies. I should also note that I built debuggable files. I didn't strip the diagrams, which certainly could make a difference. Another thing we noted is that if we build nonLabVIEW files (e.g., configuration files) when we build a sublibrary, we have to include those files as well in the build definition for any callers if we want to include them in the destination directory for the caller's build. Moreover, the caller's destination directory includes a copy of the sublibrary builds as well, which I understand because it makes it easy for the caller to find them and be sure to have the correct version, but it does mean that if you rebuild a sublibrary you have to then rebuild the caller (that is, if you want to reuse the new version) or copy the newly built sublibrary wherever it is used (which I understand will be legal if the interface hasn't changed). This presents a bit of a maintenance problem. Probably the easiest thing is to rebuild every caller in a hierarchical fashion, but right now we don't have a tool to facilitate that process. We have to be savvy maintainers or build our own batch build tool. (We attempted to get around this by putting all the builds in the same directory but LabVIEW won't build the caller if its dependencies are already in the destination directory. NI already thought of that and defeated it.) So... have packed project libraries been useful to you? If so, in what way? How do you handle maintenance issues (making sure you have the right versions of the packed project libraries where you want them)? Do you just stick with project libraries unbuilt (with which you may have only a single copy!)? Do you use project libraries at all? (Not so long ago we didn't much at all but my current thinking is they are critical to facilitate effective code management.) What best practices have you learned to share with the community of LabVIEW developers and, of course, advanced virtual architects?

The first time I heard mention of PPLs (beta), I thought it would be a cool way to distribute my general reusable component code, exposing only the public VIs and having everything that is private, hidden and locked away. However (as Jim pointed out to me then), as you are compiling the PPL for a specific target and LV version, so it is not (general) reusable friendly. Therefore, I see the PPL being used within an single platform Application to speed up the build time and compliment the changes to the compiler that now result in a greater build time. So reuse in an Application context, not in a general context would be a role. I can also see benefits of it with RT, i.e. downloaded one file, instead of many. However, I have not dived deep into this feature yet (we am still on LV2009 anyways) but am interested to hear other user experiences.

Haven't tried them out yet. Absolutely. All my code is in a library of some sort... either a lvlib or a class. Usually a class inside a library. - Use lvlibs to divvy up your application into modules; it helps keep your code organized. As an added bonus libraries make it a little easier for multiple developers to work on the same project. Much less fighting over who gets to checkout the .lvproj file. - Make liberal use of privately scoped classes inside a lvlib. Typically a module has too much functionality to fit inside a single class. Break the module's functionality into separate classes and make them private. Expose the needed higher level functionality through a few public api classes. Your modules will be much easier to use. - Tight coupling within a module = good. Tight coupling between modules = bad (usually.) - If you persist your classes objects to disk, don't change their namespace... ever. That resets all the internal mutation data. - Give your libraries descriptive names. Letters are cheap... don't be a scrooge. - Always, always, always be aware of your dependencies between modules. Avoid cyclic dependencies.