LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TreeControl does not store values on close

Hi all,

 

If I remember correctly, prior to 8.5.1 (which I'm using now), the Labview treecontrol value persists through even a pc restart.   When the vi is reopened the treecontrol value was there, right where I left it.  Now it seems to revert back to a default value, not its last value.  Is there a setting buried somewhere that controls this behavior?  Or will I have to use vi server to set the default value with a separate vi?  Any tips would be much appreciated.

 

thanks,

George

 

p.s. I'm running XP pro, labview  8.5.1 pds

0 Kudos
Message 1 of 8
(3,190 Views)
There is no real reason for the tree control to persist its value. It's a control like any other control, and when it loads it loads its default value, which is saved with the VI. If you were seeing that behavior (which I've never seen), then it was a bug, and you should not have relied on it, as the bug would eventually be fixed, thereby breaking your code. You should always set controls to what you want them to be either by setting the default values, or by programmatically setting the value(s).
0 Kudos
Message 2 of 8
(3,186 Views)

"gharris" <x@no.email> wrote in message
news:1222785608329-784850@exchange.ni.com...
> Hi all,&nbsp;If I remember correctly, prior to 8.5.1 (which I'm using
now), the Labview treecontrol value persists through even a pc restart.
&nbsp; When the vi is reopened the treecontrol value was there, right where
I left it.&nbsp; Now it seems to revert back to a default value, not its
last value.&nbsp; Is there a setting buried somewhere that controls this
behavior?&nbsp; Or will I have to use vi server to set the default value
with a separate vi?&nbsp; Any tips would be much
appreciated.&nbsp;thanks,George&nbsp;p.s. I'm running XP pro, labview&nbsp;
8.5.1 pds

I think your memory is wrong. The tree control is always empty, even if you
remove the VI from memory, and reload it again.

Instead of using VI server to set the value to default (which won't work in
executables), it's much better to store the data you use to fill the tree
with, and store that data in a reloadable format...

Regards,

Wiebe.


0 Kudos
Message 3 of 8
(3,184 Views)

>
> I think your memory is wrong. The tree control is always empty, even if
you
> remove the VI from memory, and reload it again.

This is only partially right.

If you edit items, and then save the VI, the data (tree items) is stored.

But this behavior is the same in 8.5.1.

In both versions, the value is not stored by saving the VI. You need to make
the value fefault, and then store the VI.

> Instead of using VI server to set the value to default (which won't work
in
> executables), it's much better to store the data you use to fill the tree
> with, and store that data in a reloadable format...

The data in the tree has nothing to do with it's value. The value is it's
selected item. So setting the default value with be set by Make Current
Default. The data in the tree (the items) will be stored because you store
the VI.

If you only need to store the items, saving the VI will be enough.


0 Kudos
Message 4 of 8
(3,184 Views)
I'll bet I was always saving the vi and didn't realize that it was saving the tree contents.  And I was talking about the tree contents, not the control value - sorry about the confusion.  So the saving works with the vi, but how can that be implemented in an executable?  
0 Kudos
Message 5 of 8
(3,166 Views)

I played with saving the tree to an ini file and building a new tree from the ini file.  its plenty fast.  This doesn't keep track of which items are open or closed, but that could be added without slowing the process down noticeably.

 

Thanks for everyone's help

0 Kudos
Message 6 of 8
(3,154 Views)
If you do this for a large number of items, it will become slow. Very slow.
We're talking about >100 items.

To speed it up, turn Differ Panel Updates on, then do the update, then turn
it off again. Or hide the tree, do the updates, make it visible again.

Updates that take 5 seconds can be done well within a second by doing this.

Regards,

Wiebe.


0 Kudos
Message 7 of 8
(3,141 Views)

Will do. 

Thanks again,

George

0 Kudos
Message 8 of 8
(3,131 Views)