Jim Kring

I did some poking around and see that this question has been asked before -- here are some stack overflow threads on the topic. It seems that the general consensus is that unit testing private functionality makes the test code-base more rigid and should be avoided. That said, I like to be able to gain the benefit of violating encapsulation with tests, where needed, provided that I understand the risks and costs. I guess we'll all have to spend some more time unit testing our code and come back here with our experiences

Once friend classes are available in LabVIEW (and this is likely to be on the roadmap) then a class under test can declare the testing class as a friend, so that the testing class can call the class under test's private methods. Regarding whether it is good or necessary to perform tests on private methods... In an ideal world you would probably never need to test private functionality because testing the public interface of a class should be sufficient (since you'll only ever need to use a class through its public interface). However, we're in a real world where we have to make compromises due to limitations in our tools and in our architectures in order to create working software within a reasonable amount of time. I think it was on Jeff Atwood's blog that I heard something to the effect of: In theory, there's no difference between theory and practice; but in practice, there is. Another strategy (aside from making the test VIs members of the class under test) is to put anything that needs to be tested outside of the class under test. For example, if they are generic support functions, you could put them into another lvlib and make them public.

QUOTE (Callahan @ Jan 25 2009, 01:15 PM) For VIPM related questions, you should probably post to the JKI Software Forums. We often post "How'd they do that?" articles. I'll ping the VIPM team to see if they could write a short article on the LabVIEW Version Selector ring. Cheers, -Jim

Here is my position on the topic: Scripting is out there and many people are using it to create some amazing tools for assisting LabVIEW development and automating various tasks. I'd like for NI to give us its blessing to create such tools, so that we don't feel like renegade outlaws and can feel comfortable sharing them with others. And, I'd love for NI staff to be able to contribute to the technical discussions around scripting -- the current position from NI seems to be that it doesn't exist. Bottom line, machine readable and writable source code is a prerequisite for creating software engineering tools. And, it would be great for NI to empower the LabVIEW community to create better software engineering tools for LabVIEW. Bottom line: I think that it would be of great value to let the LabVIEW ecosystem create innovative features and tools on the LabVIEW platform. It's a win-win situation.

I just read this and thought it was funny.

QUOTE (jed @ Jan 16 2009, 11:35 AM) You can use the ActiveProject property of the MenuLaunchApp. If this is a null ref, then you know it wasn't launched from a project.

QUOTE (jed @ Jan 16 2009, 11:35 AM) You can use the ActiveProject property of the MenuLaunchApp. If this is a null ref, then you know it wasn't launched from a project.

I wish I could remove a splitter, while preserving child splitters.

I wish I could remove a splitter, while preserving child splitters.

QUOTE (crelf @ Jan 12 2009, 07:03 PM) Well, the pain that a fully automated build cures is far worse than the pain of maintaining the code. If I'm a new developer on a project and want to make a build and all I have to do is open "Build My Project.vi" and press the run button, then I can't help but not make any mistakes. And, if I want to understand how the build process works, I can always look under the hood. As time goes by, your SOPs will become embodied in reusable code used in your build VIs -- heck, you could even package these up using VIPM, so that you don't have a custom builder for each project

QUOTE (crelf @ Jan 12 2009, 06:05 PM) IMO, the best way to do this is to create a "Build My Project.vi" that calls "<LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi" to build your Project's build spec of interest. You can put whatever pre/post tasks you want in there, in addition to sequencing multiple build specs.

QUOTE (jgcode @ Jan 8 2009, 11:02 PM) Oh great. I haven't even started working with Vista seriously and now I need to start thinking about (and avoiding) Windows 7. I wonder if Vista will just be like Windows ME and we can all just agree to forget about it, eventually.

Here's some more, related, buggy behavior. When you drop a Merge VI onto a Front Panel, all Block Diagram objects of the merged VI are selected in the Front Panel -- this allowing easy repositioning, which is a nice feature. However, When you drop a Merge VI onto a Block Diagram, only the Front Panel decoration objects of the merged VI are selected (the controls and indicators are not selected). I would assume that this is a bug and that the controls and indicators should be selected, too, along with the decorations. Here's another screen capture movie that demonstrates this: And, here's the new example that I used in this video: Download File:post-17-1231196007.zip Status update: Reported to R&D (CAR # 139212)

Description Front Panel objects of merged VIs (set to "Place VI Contents" in the palette editor), especially decorations, can be re-positioned relative to each other and the Front Panel when placed from the installed LabVIEW palettes into a block diagram. Screenshot Example (with audio) Steps to Reproduce 1) Create a VI with some front panel controls and decorations (noting the relative positions of the FP objects) 2) Add this VI to a palette and configure it to Place VI Contents (when dropped), using the palette editor 3) Drop the VI onto a block diagram and note the relative positions of the FP objects Observed Results The relative positions of the FP objects are different from the original VI Expected Results The relative positions of the FP objects should be the same as the original VI Test it for Yourself Extract the "test merge" folder (from the attached test_merge.zip file) into the "user.lib" folder, restart LabVIEW, and then drop Functions Palette >> User Libraries >> test merge >> test merge.vi onto the block diagram of a VI. Download File:post-17-1231020958.zip

QUOTE (Aristos Queue @ Jan 3 2009, 06:40 AM) > suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards Only if one used improper settings that allowed the .svn folder contents to be included -- the .svn folder contents should be exclude-able in the build spec scheme. The general pain that I'm describing is caused by the fact that you can only "build" things (exe, zip, installer) from sources that exist in your project. Building a software product typically involves several cascaded build steps (in most situations this is an EXE, followed by an Installer, followed by a ZIP file). The project environment bonks when it can't find project items. And inputs to a build step generally don't exist until a prior build step completes -- this is why, IMO, it doesn't make much sense to require that items exist in the project in order to build them (since the auto-populating folder scheme is so "dumb" in how it auto-populates). Plus, projects (and auto-updating folders) don't update/refresh between build steps. Maybe you could use multiple projects, but this is also a bit of a kludge and means that you can't build in a single step -- it also means that you can't open a downstream project until an upstream project is built. Bottom line: using the project environment to build any non-trivial software product is a painful endeavor -- you should http://thinkinging.com/2008/05/27/a-dogfooding-challenge-to-ni-use-your-application-builder/' rel='nofollow' target="_blank">try it sometime

QUOTE (Aristos Queue @ Jan 2 2009, 03:05 PM) Yes.

QUOTE (rolfk @ Jan 2 2009, 12:38 PM) Actually, for VxWorks support, after installing the lvzip package, you should ftp "<LabVIEW>\user.lib\_OpenG.lib\lvzip\lvzlib.out" to the RT controller into ni-rt\system. The package installs the correct version of lvzlib.out, depending on the LabVIEW version into which it is installing the package. I've added this note to the http://wiki.openg.org/Oglib_lvzip' rel='nofollow' target="_blank">oglib_lvzip page.

QUOTE (Yair @ Jan 2 2009, 01:07 AM) I believe that the only good reason for using auto-populating folders is due to a limitation in the build spec scheme that requires any file that will be included in the zip/exe/installer to exist in the project (ideally, we should be able to create installers from items on disk using wildcards and optional recursion, rather than just items in the project). Hence, if you want to include all files in your "images" folder in your installer, without updating your project or build specifications every time you add a new image to your images folder, you can make your images folder auto-populating and then in your build specs add this auto-populating folder to the installer.

QUOTE (sam @ Dec 31 2008, 10:51 AM) That's odd, because all the files below the ".svn\text-base" folders should be suffixed as "*.svn-base". In your screenshot, they are missing the ".svn-base" suffix.

QUOTE (sam @ Dec 31 2008, 07:43 AM) Which LabVIEW version are you using? Are you using auto-populating folders or did you add the .svn folder contents to your project? In older versions of LabVIEW, auto-populating folders didn't ignore hidden folders (.svn folders are typically "hidden"). That's the only way that I know of that would cause you to get the cached repository VIs (located beneath .svn) in your project. These cached repository VIs have different file names, so LabVIEW should never relink to these unless you tell LabVIEW to do so, or accidentally use one of them in your project. Or, did you do a mass compile (Tools>>Advanced>>Mass Compile) operation? This can cause problems, because LabVIEW will attempt to mass compile the cached repository VIs. This may have been fixed, but I don't think so -- I avoid the Mass Compile tool. QUOTE (Ton @ Dec 31 2008, 09:21 AM) I would try to get a clean repository, the easiest is to commit everything to the repository, remove the .svn folder. Then set SVN to use _svn folders instead of .svn folders. ( I know this is possible with TortoiseSVN). Now if you open up a VI with false links, LabVIEW will start searching (but will ignore the _svn folders) and you can relink. Ton QUOTE (Aristos Queue @ Dec 31 2008, 10:00 AM) What causes LabVIEW to ignore _svn directories? Is that something built into LabVIEW? There are a variety of situations where LabVIEW ignores any folder/file that begins with an underscore. For example: populating the palettes (synchronize with directory) populating the Tools, File, and Help menus with menu-launch VIs However, I think Ton's assertion might not be true -- I don't believe that auto-populating folders or the search dialog ignore underscore-prefixed files/folders.

QUOTE (mballa @ Dec 23 2008, 07:17 AM) The other champs are Buddy Haun (hat) and Albert Geven (beard). And, the NI guy on the far left is Todd Sierer.

QUOTE (crelf @ Dec 22 2008, 07:34 AM) Is it my fault that the hot photographer babes are always taking my picture? Probably, since I'm http://thinkinging.com/2007/08/17/front-row-tickets-to-niweek/' rel='nofollow' target="_blank">always in the front row.

I've noticed problems when the class data contains a queue/notifier/event reference that includes the class data type -- this is a recursive type definition. You should (do as Tomi suggested and) make your Notifier use a generic LVClass reference and then upcast it to the more specific type after you receive the notification. This solution works very well and is how we solve this problem at JKI.

QUOTE (lenny wintfeld @ Dec 17 2008, 02:41 PM) Hi Lenny, I'm happy that you're making progress in learning LabVIEW with LabVIEW for Everyone and that you found the LAVA forums Cheers, -Jim

Hi Ton, I think that we should position the discussion topic as: Is a Polymorphic VI a good mechanism to conveniently access the members of a "library" (set of related) of VIs? The main problem that this technique solves is that there is no easy way in LabVIEW (without using palettes) to access the other members of a library from an existing member (or reference/lvobject) on the block diagram. For example, Property Nodes and Invoke Nodes provide quick access to a menu of available properties and methods of various "objects" -- we need something similar for lvlibs, where we can quickly access other members. So, what are the pros and cons of using the PolyVI in this way? Pros Can use the poly selector terminal Can show instance icons Nice menu structure that can be used to group related functions All VIs must have the same connector pane pattern. (This is a "pro" if you like to enforce that all VIs must use the 4-2-2-4, or other, pattern. See "con" below) Cons: All VIs must have the same connector pane pattern. (This is a "con" if you use different patterns for different VIs. See "pro" above.) It is not an expected/standard (yet) use of poly VIs Can anyone else think of other pros and cons, or have comments on the ones that I listed? Of course, this technique involves using a LabVIEW feature in a way it was not intended, but this wouldn't be the first example of overcoming a major LabVIEW limitation through creative use of other features. I'm starting to think that if we educate the LabVIEW community on this clever use of polyVIs that it might be a very useful tool. Another side note is that polymorphic VIs are actually just a work-around for two major limitations in LabVIEW: run-time (true) polymorphism (such as that which was finally made available in LVOOP) "anything" (undefined) datatype/control (that can be used to propagate wire data type, at edit-time, from a subVI's conpane terminals to polymorphic inputs of primitive functions and inputs of subVIs with undefined inputs). So, there's really no reason (aside from the name "Polymorphic VI") that polymorphic VIs should be used only for edit-time switching between psuedo-polymorphic VIs. The polymorphic VIs is really just a convenient editing tool that allows the user switch between an organized set of VIs at edit-time, which is what we're trying to do, here. :2cents: -Jim PS - great idea, Ton!