Is a tree item its own sibling?

[richferrara]

I have a routine that takes a tree item selected by a user and loops through all of the item's siblings:

itemRelated = TRUE;
treeItemToTest = 0;

while ((itemRelated) && (treeItemToTest < totalTreeItems) && 
    (treeItemToTest >= 0))
{
    /* Check if file is related to the selected file */
    AreTreeItemsRelated(panelHandle, treeHandle, 
        treeItemToTest, VAL_SIBLING, selectedTreeIndex,
        &itemRelated);
        
    if (itemRelated)
    {
        /* process the item */
        /* ... */

        ++treeItemToTest;
    }
}    

Somewhere in between CVI 2012 and the current version, our program stopped working correctly.  I traced the problem to the AreTreeItemsRelated call in this routine.  In the latest version of LabWindows, this call will return FALSE if treeItemToTest and selectedTreeIndex are the same item.  This is apparently a change in behavior from CVI 2012, but it is not documented in the function help.  Was this change deliberate?

[richferrara]

I just found the answer to my own question in the CVI 2013 release notes.

http://www.ni.com/white-paper/14686/en/   (#388199)

I think this function's operation made more sense the old way precisely because of loops like the one we're using.  Perhaps there should be another option available such as VAL_SIBLING_OR_SELF for this purpose?

[jared]

Another option is to iterate through the siblings with a loop like this:

GetActiveTreeItem(panel, tree, &index);

for (GetTreeItem(panel, tree, VAL_SIBLING, index, VAL_FIRST, VAL_NEXT_PLUS_SELF, 0, &index);
	index >= 0; 
        GetTreeItem(panel, tree, VAL_SIBLING, index, index, VAL_NEXT, 0, &index)) 
{
        SetTreeItemAttribute(panel, tree, index, ATTR_SELECTED, 1);
}

[richferrara]

I noticed something troubling about this error: Because this function call runs out of the LabWindows run-time engine, it can cause a previously installed program to stop working.

My department has multiple LabWindows programs running on some PCs.  Let's say I do the following:

1. Install program #1 (built with an old CVI RTE version).

2. Install program #2 (an unrelated program built with CVI 2013, including the new RTE).

Program #1 will now be using the CVI 2013 RTE.  If there is a difference between the two versions such as the one I described, this can cause program #1 to stop working.

Worse, the RTE cannot be downgraded back to the original version.  If I try to do this through the Control Panel, the NI uninstall program tells me that in order to uninstall the new RTE, I also have to uninstall all the programs that are using it (which would include program #1 in my example above).

There should be an easier way to revert a run-time engine installation without having to uninstall all LabWindows programs together.

[LuisG · Accepted solution]

Yes. you're right. You've run into a scenario that can be very difficult to work around. We try very hard to never break compatibility with earlier versions of the run-time, but sometimes that is unavoidable, such as in cases like this where a bug is fixed in a new version. Problems happen when there are existing programs that are assuming the existance of that bug, and would actually break if it weren't for the bug.

The best way to avoid ending up in this situation is to use a version-specific flavor of the CVI run-time. It has its downsides too, of course (such as not automatically benefiting from bug fixes in the run-time) but it might safer in complicated deployment situations.

Of course, that doesn't really help you now, since your "program #1" is already deployed using the shared run-time. Given this, the best you can do is to replace it, which you can do without uninstalling all of its dependencies, by following these steps.

Luis