OpenXTalk Forums

This is freaky-bizarre:

https://forums.livecode.com/viewtopic.p ... 0&start=15

the effective visible

Effective visible works, but effective visibility doesn't.
Haven't tried stuff in nested groups yet.

Seems like you can GET the effective visible, but SET the effective visible produces a script error.

From dictionary:

The effective keyword can be used with the following inherited properties : * backgroundColor property * backgroundPattern property * backgroundPixel property * bottomColor property * bottomPattern property * bottomPixel property * focusColor property * focusPattern property * focusPixel property * foregroundColor property * foregroundPattern property * foregroundPixel property * hiliteColor property * hilitePattern property * hilitePixel property * topColor property * topPattern property * topPixel property * shadowColor property * shadowPattern property * shadowPixel property * textFont property * textHeight property * textSize property * textStyle property * filename of stack property * rectangle property * layerMode property *Note:* The effective keyword is implemented internally as a property and appears in the propertyNames. However, it cannot be used as a prop in an expression, nor with the set com[mand].

So, you can only GET the effective [something], you can't SET the effective [something] the dictionary says.
However, "get the effective visible" is not mentioned in the dictionary, so while correcting this dictionary entry for typos (of which there are many) and formatting errors (of which there are many), it might well be worth adding in.

edit: dictionary entry corrected (text version), and formatting also sorted out. Will add this in v1.09 of OXT lite. As well as adding "visible" to the list off things supported by "effective" (on the above screenshot), I also just added a second example:

Very badly documented, if at all, and in many cases counterintuitive.

It's very misleading, because you can do: which the dictionary says you can't set the effective.

but then, you can use: (answers "true") -- all it's done is set a custom property on the stack.

The same as using:
set the flipflop of this stack to true. It's ignored the 'effective' part, and that should really throw an error.

Some person has shown that they can be extremely inconsistent, and it reflected in their work.
-

Certainly makes you wonder how deep the rabbit hole goes...

So, as bn suggests, in that 'other place' - searching for 'visible' in the dictionary does mention the effective visible: As I had the dictionary open anyway...
If you wanted to toggle visibility of the stack by using 'effective visible', you'd have to do: Just doesn't seem very intuitive that you can't set the effective visible. But there you go.

A good way to find out is to try SET the effective [something] of btn "button" to "1"
If it's suddenly got a custom property listed under [something], then it's not a supported thing for the GET effective command. If it errors on you, I think there's a good chance you could switch it around and use it for GET. (if that makes sense?)

What I mean by that, is: That works. But shouldn't. It's not mentioned in the dictionary!
Yet: returns nothing!! (not even an error)

Where's my rabbit emoji?


This ALSO should not work, but guess what It does! -- the dictionary says you can't

The effective keyword [... blah blah...] However, it cannot be used [...] with the set command.

This would appear to be wrong.

The latest question from 'that other place' (if you are following along, popcorn in hand)

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?

Hmmm. Let's try it! Works like I'd expect in 9.6.3 (9.7.0-dp1)
So, question is - did they mess this up somewhere in 9.6.9?

did they mess this up somewhere in 9.6.9?

I have a feeling quite a lot was messed up.

Of course conspiracy theorists might claim that was to make people rush to adopt Create.

Or they could always rush over here.
Do you want to tell them the bug does not seem present in 9.6.3 (or 9.7.0-dp1) ?
Might help narrow it down.

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

I'm going to have to remember that one!