This pull request needs to be attached to the release-6.0.1 branch instead of master.

Well, technically it should be against master - but without the stuff from release-6.0.1 merged in ;)

However, the master branch has a few minor issues with regards building on Mac at the moment unless you have Xcode 3.2.6 so doing stuff without the release-6.0.1 is a little tricky.

It's no problem though it should just resolve to (Monte's) final commit when merged in.

Yeah... sorry, this was a half hearted attempt to follow procedure. Once release-6.0.1 is merged in it will be easier to branch off master but for now I can't both work off master and build. However, I realise now that seeing as I branched off release-6.0.1 I should have just sent the pull request against it so it was more obvious that it's just a small change...

Just taking a look at this... And it turned up a couple of things.

The effective visible computation isn't quite right. The parent pointer will change from group, through card to stack and mainstack (if the stack is a substack). Thus, you'll end up with the effective visible returning true for objects on an invisible substack that is part of a visible mainstack - the search needs to stop at the stack level.

The other thing is related to the proposal to make getprop() / setprop() send messages. Should 'the effective visible' use getprop() and thus potentially call a getprop handler? If the getprop() for visible is overridden in a parent object it might return something which is not in-sync with the actual objects visibility. Thus meaning 'the effective visible' returns (essentially) an invalid value. i.e. When you do 'the effective visible' should it be the actual visible state of the object as seen by the engine, or after potential modification to the values by script? If it should be the actual visible state then it would be better to use the 'isvisible()' method of MCObject, which does the recursion 'internally'.

The effective visible computation isn't quite right. The parent pointer will change from group, through card to stack and mainstack (if the stack is a substack). Thus, you'll end up with the effective visible returning true for objects on an invisible substack that is part of a visible mainstack - the search needs to stop at the stack level.

Ah... good point... Um... wonder if it should stop at card...
The other thing is related to the proposal to make getprop() / setprop() send messages. Should 'the effective visible' use getprop() and thus potentially call a getprop handler? If the getprop() for visible is overridden in a parent object it might return something which is not in-sync with the actual objects visibility. Thus meaning 'the effective visible' returns (essentially) an invalid value. i.e. When you do 'the effective visible' should it be the actual visible state of the object as seen by the engine, or after potential modification to the values by script? If it should be the actual visible state then it would be better to use the 'isvisible()' method of MCObject, which does the recursion 'internally'.

Hmm... if someone has bothered to script visible to return an incorrect result then they might want effective visible to return that.

Whether it should stop at card or not depends on what 'the effective visible' should actually do... There are two choices:

1. It returns 'true' if the control is actually visible on the screen (in which case it should ignore the card setting and check the stack setting)
2. It returns 'true' if the control would be visible assuming the stack it is on is visible (this is the semantics of isvisible() which is only used in cases where the stack is already visible).

In regards to the latter thing about getprop() messages - you are probably right - caveat scriptor :)

On 19/04/2013, at 7:37 PM, runrevmark [email protected] wrote:

Whether it should stop at card or not depends on what 'the effective visible' should actually do... There are two choices:

1. It returns 'true' if the control is actually visible on the screen (in which case it should ignore the card setting and check the stack setting)
2. It returns 'true' if the control would be visible assuming the stack it is on is visible (this is the semantics of isvisible() which is only used in cases where the stack is already visible).

I personally think 2 and I think that's what most people would expect. It should check all parent groups are visible I think.
In regards to the latter thing about getprop() messages - you are probably right - caveat scriptor :)

OK.. I'll leave that bit

Monte Goulding

M E R Goulding - software development services
mergExt - There's an external for that!

I think I agree - (2) seems the better choice: 'the effective visible' returns true iff the control and all its parent groups (if any) are visible.

The thing about getprop() potentially calling script and returning a 'not quite true' value is perhaps something we can revisit after the engine props actually start sending messages... This is something that is going to have to be reviewed anywhere to make sure that in the places where the engine does actually use getprop(), it won't mind potentially getting 'erroneous' results.

hmm... got to remind myself not to reply via email... formatting is terrible

OK... so parent -> gettype() == CT_GROUP should do the trick then

Sounds about right :)

By the way, we won't be able to pull this into 6.0.1 as we're about to push out an rc-1 of that (the only rc we hope it will need).

However, it's another good candidate for the the next non-maintenance release so I'll pull that in when work commences there (and the 'development' branch will be born!).

ok... no rush

Hi Monte - I've merged this into 'develop' now. Thanks!