10-15-2009 08:36 AM
LV 2009. I haven't checked if this happens in earlier versions.
If you change the Disabled property of a tab control to Disabled and Grayed and then write a value to a control which is inside the tab, the control changes its appearance to look as if it's enabled.
The workaround I've found was to defer the panel updates before disabling the tab and undefer after writing the values.
10-15-2009 09:41 AM
I made a screenshot earlier, so I might as well post it:
10-15-2009 09:42 AM
11-10-2009 04:55 AM
11-10-2009 02:58 PM
Hi All,
First off I want to apologize for the delayed response. This has been reported to R&D (CAR #195503) for further investigation. I managed to come up with another work around that I hope you will find useful. Basically, you can use VI Server to access the references, and therefore the properties and methods, of all of the controls on a tab control. By taking advantage of this, you can easily set each control on a tab control to be disabled by itself. I have modified the code that you sent to demonstrate this. Please have a look at this and let me know if it will be an acceptible workaround while the issue that you reported is being investigated. I have also attached a VI Snippet of the extra piece of code that I wrote to handle the VI server operations. Hopefully this will help anyone trying to integrate this solution. Thanks for your posts!
11-11-2009 02:22 AM
11-11-2009 03:14 AM
11-11-2009 03:51 AM
Bug confirmed in LV 8.5.1.
Yamaeda wrote:
Does it react the same way with a local variable and property node?
It reacts the same way with locals, but slightly different with property nodes.
I mean there are 2 Disabled & Greyed out states for a Tab, one for the whole Tab itself & the other for the particular page(s). When using the property nodes, it turns to be enabled only when the Tab itself is not Disabled & Greyed Out irrespective of the Disabled stste of the Page Enabled State property.
I tested with these properties configured only thro' the shortcut menu option & NOT thro' property nodes.
11-12-2009 12:39 PM
Hi tst,
Deferring front panel updates does require less code, but the difference is that with that method, only the UI is affected. The controls are not actually disabled, as with the other work around. Ultimately, everyone should evaluate the needs of their own application and choose which method works the best. However, it is useful to understand what each method is actually doing.
Also, I'd like to point out that in the example workaround that I posted, I chose to disable all controls. However, it would be fairly simple to implement some code that would allow the user to choose which controls were enabled or disabled.
Thanks for your comments!