03-03-2011 01:48 PM
Solved! Go to Solution.
03-03-2011 02:12 PM
Can you post an example that demonstrates this?
03-03-2011 03:12 PM
Unfortunately I can't post the exact code here due to technicial disclosure red tape. I did try to mock up what I am doing in a seperate VI, but it works perfectly, so there must be something with my implementation of it.
I've attached the mockup VI, and although it doesn't display the bug, it does give you an idea of what I'm trying to do. Note: You will need labview 2010 and vision acquisition 2010 to open it.
03-04-2011 10:42 AM
Just guessing here but I have seen some funny things with Tab controls, especially when working with visability property. I suspect that "Under the hood" LabVIEW uses the visability property to make Tabs work.
In your example I( notied that you are writing the property every iteration. This isn't too great a method and can lead to some ineffecintcies. Also, when objects overlap on the FP an update to any overlaping object requires all the objects to get refreshed so you can lose a lot of processor time that could bog down your CPU. One possible work-around you could try is adding a secod loop with an event structure in it to catch only the changes to the visable boolean. Another thing to try would be to hit the visable property of the objects on the tab directly. A reasonable example is this snippet.
03-04-2011 10:55 AM
I agree that setting the visable option isn't efficent, in my source code it only happens once when the user hits the "hide" key, and it was just expediant to do it that way for the example.
In my code, I went ahead and changed visable property of the offending controls and that seems to have fixed it. It's a little bit of a kluge, but I will mark that as the solution. Thanks for your help.