While troubleshooting a bug, I found unexpected behavior while enabling or disabling items on a form that resides inside a tab panel when the enable property of the tab panel is also altered. From what I can see, any change to the tab panel also changes any element beneath it which seems wrong but I’m willing to listen of course.
I have a situation laid out like the following pseudo code where a layout is locked to prevent user interaction as code runs and then unlocked upon completion.
forms.top.tab.enabled = false;
run a bunch of code which includes: forms.bottom.field.enabled = false;
forms.top.tab.enabled = true;
I expect my field to be disabled and when I enable the tab above it but instead the field is flipped to enabled=true along with the tab leaving my bottom form in an unintended state.
As an additional note, the order of events doesn’t matter, in that if I ran the same code in a different order, the same behavior of the tab.enabled state resetting everything else still applies.
run a bunch of code which includes: forms.bottom.field.enabled = false;
forms.top.tab.enabled = false;
forms.top.tab.enabled = true;
Is this right?
I’ve tried this in 5.2.7-5.2.9 & in 6.0.0 1217
if you set enabled (or readonly ) on a container (tab) then everything beneath it is also set (it cascades)
But what i don’t get in your example is the relation between top and bottom…
of you do forms.top.tab.enabled = false
then i guess forms.bottom is not in that hierarchy right?
so that should be completely unrelated.
or is it so that the form inside that top.tab is the bottom?
If that is the case then this is completely not needed:
forms.top.tab.enabled = false;
forms.bottom.field.enabled = false; <<<
the only order that will work then is:
forms.top.tab.enabled = false;
forms.top.tab.enabled = true;
forms.bottom.field.enabled = false;
Yes bottom is the form inside top.tab.
Thanks for the response. It sounds like the only way to lock an interface is to use a plugin like the busy plugin versus temporarily locking a container element.
One final question, is that Java or Servoy designed behavior?
thats servoy’s behavior, when you call readonly/enabled on panels (what a tabpanel is) we cascade it so that really the whole panel is disabled
(else nothing would happen)
its the same as saying form.x.controller.enabled = false;
For that if that didn’t disable all the elements on the form, that would be just a no operation (wouldn’t do anything)
But i guess you don’t expect it for a tabpanel that it really disables all tabs not just the tabs its self.
if you would do:
forms.top.elements.tab.enabled = false
do you expect that the current visible/selected tab is fully enabled? You just can’t select another tab?
Because that would happen if we don’t cascade.
I get what you were saying and thought that was what was going on. For us it is a matter of controlling the state of our forms when fields and menus are locked due to security or other business rules while also being able to temporarily lock the interface while processing occurs. We always look for native ways to do this before branching out into plugin which is why we tried using the locking of the panel as a means to do this. We will write our own tab enable/disable methods or use the busy plugin.