hiding a group does not hide its members

[dunbarx]

Klaus.

Imagine it would be as you see it, then we would need to set the visible of ALL controls in the group to visible again

Right. I don't see anything crazy about setting the visible a group's children to false when the visible of the group itself is set that way, in other words, that they track the visible of the group.

What is the advantage of doing it the way LC seems to, having an invisible control that has its visible set to "true"? In other words, what is the disadvantage of having it track the group? Fooled me, as evidenced by my handler failing the way it did, for the reasons that it did.

I see that Bernd, as usual, has found the "real" visible property that I was seeking. And with a much shorter name.

I had set a custom property to do the job, which works fine, but using the effective visible is simpler. I wonder how many effective properties are out there.

Thanks all.

Craig

[SparkOut]

What if you have a group containing some visible controls, and some invisible ones too, then hide the group?
If the visible of all the grouped controls is set to false to match the group, what happens when you set the group visible again? Just setting all the grouped controls to visible wouldn't match the original view. Rather than have some complicated record of the original state, and calculate back from that, it's much simpler and a more natural fit with the rest of the code architecture to use inheritance, but leave the individual control property the same.

[Klaus]

...
I wonder how many effective properties are out there.

Why not take a look into the dictionary instead of wondering?

[bn]

I wonder how many effective properties are out there.

The dictionary lists for "effective" a lot of properties, though I do not see "visible" listed.
The entry for "visible" explains the use of "effective visible".

Actually I tried using "effective visible" on a hunch and it worked (as Sparkout also did) and later I looked it up in the dictionary.

Kind regards
Bernd

[stam]

I don't see anything crazy about setting the visible a group's children to false when the visible of the group itself is set that way, in other words, that they track the visible of the group.

Not sure you thought that through fully…
Any number of complex groups contain invisible elements.

For example a button for behaviour scripts - this will always have its visibility set to false no matter what the state of the parent group.

Many of the groups I create have elements that are conditionally shown or hidden based on the group’s settings. It would be disastrous if groups behaved the way you suggest…

[dunbarx]

I see the points made. I would have thought that a group could keep track of the visible status of its members, keep that faith, and live in peace with them all.

Breaking news.

If I make four buttons on a new card, group two of them, and then hide the group, both the effective visible and the visible of those two buttons remains "true". This is in 9.6.9. Has it really changed in 10? If so, why would it, if not to address a peccadillo in LC where an unseeable control is still "visible"? Someone in Scotland had to make that decision and change the engine. Now why would that have come up?

For me now, I will stick with the custom property that I created to determine which controls are seeable, since any sort of visible is not an option. That I have to do something like that raises no eyebrows from anyone? Not that such a method is not simple and workable, but that the existing way LC works requires it?

Craig

[Klaus]

If I make four buttons on a new card, group two of them, and then hide the group, the effective visible of those two buttons remains "true". This is in 9.6.9. Has it really changed in 10?

Returns TRUE in LC 10.0.0, too!

[dunbarx]

Klaus. Bernd.

Returns TRUE in LC 10.0.0, too!

??

But if so, then there is no, er, effective way to know the "visible" status of a child control that is a member of a hidden group. One cannot rely on any "visual" status at all.

Odd.

Craig

[dunbarx]

Klaus.

Why not take a look into the dictionary instead of wondering?

I did look in the dictionary, which is why I posted (posited?) that there were other unlisted variants of the "effective" property, and wondered what they might be. The ones listed, again, have mostly to do with colors and text, reasonable since they address the inherited properties of larger things, like cards. That list is incomplete.

The most important effective property for me is the "effective points", nailed a few years ago by Bernd in:
viewtopic.php?f=7&t=34911&p=198257&hili ... ts#p198257
No other points would do. If such a powerful variant exists with points, what others might be available for exploitation?

Craig

[Klaus]

Hi Craig,

sorry, I tried but I'm not able to relate to your thinking.

Could you please give a little example where it is neccessary
to know about the effective visible of a control? Thanks!

And yes, the dictionary lacks a lot of entries.

Best

Klaus

[bn]

Breaking news.
If I make four buttons on a new card, group two of them, and then hide the group, both the effective visible and the visible of those two buttons remains "true". This is in 9.6.9. Has it really changed in 10? If so, why would it, if not to address a peccadillo in LC where an unseeable control is still "visible"? Someone in Scotland had to make that decision and change the engine. Now why would that have come up?

Craig,

I made a new stack in 9.6.9 (also in 10.0.0 Rc1 and R2) with 4 buttons, then I grouped the last two buttons and hid the group.

From the message box I queried the "effective visible" of all 4 buttons, also the "visible" of all 4 buttons:
The result was as expected in all Lc versions tested:
buttons 1 and 2 (the visible ones) returned always true
buttons 3 and 4 (the ones in the hidden group) returned true for "visible" and false for "effective visible"

Kind regards
Bernd

[dunbarx]

Bernd.

Maddening. I just made a new test stack from scratch, and confirm what you saw. The "effective visible" does indeed show what the human eye sees.

Great to know, and I may go back to using that property instead of the custom prop.

Just goes to show that "effective" can be pretty effective. Wish I knew what others there are.

Thanks...

Craig

[dunbarx]

Klaus.

Could you please give a little example where it is neccessary
to know about the effective visible of a control? Thanks!

I am adding functionality to a large project. I need to be able to show and hide certain groups, with each group owning several buttons. Some of the buttons in each group are either hidden or shown when the group itself is shown, depending on other circumstances. But when a group is hidden, I was unable to access the child buttons using their "visible" property. I originally assumed that they would all have that property set to "true"; they do not.

But if I use the "effective visible" property, then the buttons of any hidden group are themselves (effectively) hidden, and so not just visually.

Craig

[jacque]

Think of it as a cloaking device. Suppose you have a house with one of those. People outside cannot see the house, but if they can find the door and go inside, all the furniture and other contents are visible. Everything is still there as usual.

The current behavior makes it easy to show or hide whole sets of controls without disturbing the contents. It's been that way as long as I can remember.

[dunbarx]

Jacque.

I get that. But I have mixed "visible" and "hidden" controls in each group that visually fluctuate wildly as each group was displayed and processed, depending on lots of other circumstances. I thought that the visible property for a group would translate similarly to the visible properties of its children.

It does not. But the "effective visible" property does, and that works just fine for my purposes. Funny how that variant, just like in the "effective points" property used in that other thread I posted, is so much more, to my way of thinking, "correct".

Ha Ha.

Craig