Jim Kring

QUOTE (Val Brown @ Feb 4 2009, 12:41 PM)

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

Don't forget that text-based languages are inherently open, in the sense that you can use any editor to read and modify the sources.

QUOTE (Jim Kring @ Feb 14 2007, 05:39 PM)

Tomi,

Here is a link to a simple technique that I use for unit testing OpenG libraries:

http://forums.openg.org/index.php?showtopi...post&p=1120

To close the loop, on this thread...

JKI has just released VI Tester, a software (unit) testing framework for LabVIEW. See here for details:

http://blog.jkisoft.com/news/jki-announces...se-in-jki-labs/

Thanks,

-Jim

You might have seen the announcement, already, but JKI has just released VI Tester, a software (unit) testing framework for LabVIEW.

See here for details:

http://blog.jkisoft.com/news/jki-announces...se-in-jki-labs/

Thanks,

-Jim

QUOTE (Herbert @ Feb 2 2009, 10:10 PM)

Sometimes it's worthwhile adding and maintaining a white box test, sometimes it's not ...

Hi Herbert,

That's basically how I feel, too. It's nice to hear you say it

(...even if I'm wrong, in theory)

Cheers,

-Jim

QUOTE (Omar Mussa @ Feb 2 2009, 06:33 PM)

Sort of, a lot of people are use 'Reflection' (google reflection and unit testing if you don't believe me ) to dynamically scope the private methods as public in order to test them (using other languages like java). I can imagine all kinds of s*!@ hitting the fan when doing that in LabVIEW since any class methods that happened to have the same name as the method you changed to public would be broken (due to not having dynamic dispatching enabled but being a part of the same class hierarchy).

Also, so far this http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html?page=1' rel='nofollow' target="_blank">link was the easiest for me to understand regarding reflection and unit testing -- I'm not a java programmer but its fairly digestible.

Well, writing tests that call private methods means that your tests are broken. Sure, you could make the methods under test public before running the tests via reflection (so that the tests aren't broken when the tests are run), but who wants to do development on VIs that are normally broken?

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)

Hello everybody,

I have a simple question about the VIPM GUI :

How is made the LabVIEW version ring selector (see png file) ?

It has a image inside it, but it is clickable...I try a lot of ways to do that...customize system rings...but I don't succeed...

Anyone as THE solution?

(I supposed that the solution is simple, but sometimes it's hard to do simple...).

Best regards,

Callahan

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)

I am having trouble using the App.MenuLaunchVI property (super secret, I think).

The problem is with projects. When called by a VI launched from the Tools menu of a project window, the property returns "_ProjectWindowX" where X is some number.

I cannot find a way to use that string to get a reference/path to the project window in question.

Right now, if I see "_ProjectWindow" at the front of the string, I handle it differently than other type of files, and just get a list of project references in memory, then pull the first one off the top (this only works because I usually only have 1 project in memory). But this is obviously a bad way to do it.

any ideas? Ultimately what I am looking for is a way to get the Project Ref from a VI launched via its menu.

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)

I am having trouble using the App.MenuLaunchVI property (super secret, I think).

The problem is with projects. When called by a VI launched from the Tools menu of a project window, the property returns "_ProjectWindowX" where X is some number.

I cannot find a way to use that string to get a reference/path to the project window in question.

Right now, if I see "_ProjectWindow" at the front of the string, I handle it differently than other type of files, and just get a list of project references in memory, then pull the first one off the top (this only works because I usually only have 1 project in memory). But this is obviously a bad way to do it.

any ideas? Ultimately what I am looking for is a way to get the Project Ref from a VI launched via its menu.

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)

True - thanks for reminding me of that. That said, maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure, but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own.

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)

A custom batch file is certainly an option, but I'd need to be able to have it run automatically pre- and post-build. Anyone got any ideas on how to do that? In fact, pre- and post-build hooks would be very useful (eg: build some documentation, etc).

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)

My LabVIEW 8.6 installer does not work with Windows 7 Beta

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)

Why? Wouldn't that make the situation described here worse? You would conceivably have a project that works perfectly well in development, then you build an EXE and 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. What can you pick up in a build spec that you cannot pick up in the project itself?

> 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)

Ideally you what?! Weren't folks just complaining about cross-linking? Yes. And yet now you want to add it as a feature for build specs. *sigh*

Yes.

QUOTE (rolfk @ Jan 2 2009, 12:38 PM)

For VxWorks support you should ftp the according lvzlib.out to the controller into ni-rt\system, from the correct subdirectory (vxWorks82 for LabVIEW 8.2.x and vxWorks85 for LabVIEW 8.5.x and 8.6) inside the lvzip directory created where you installed the package.

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)

Can you expand on that? I only really started using 8.x recently and would prefer avoiding it if there are good reasons.

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)

I am attaching this Picture to show VIs linked incorrectly. Notice how ".svn" is a parent folder for the VIs

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)

Hi,

I have a concern regarding SVN. I have been using SVN since/before 2004. Lately I am having a lot of VIs that are incorrectly linked to the .SVN folder; I am blaming the project explorer. I am having a lot of frustration with this, and hate the fact that I need to relink more and more VIs to the actual file from the temporary SVN file. If there isn't a solution found for this incorrect linking I will abandon my favorite SCC.

Has anyone else ran into this? What do you do to avoid false linking?

As always I appreciate your kind help.

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)

QUOTE (Aristos Queue @ Dec 31 2008, 10:00 AM)

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.