visibilityChanged and controlMoved messages

[monte]

Hi

I'd like to implement the following new messages to be sent to objects when either their property changes or one of their parent groups moved or changed visibility. Without these two we can't create custom controls that allow a native control to mirror their visibility and rect. If a parent group is hidden or moved all child objects need to get the message. They could be only conditionally sent.

Cheers

Monte

[LCMark]

This is a good idea.

Part of me did worry slightly initially about the performance implications in setting visible or the rect props on groups, but since both those things tend to engender a complete redraw of their rect that effect I don't think that would be an issue.

The only thing I wonder is whether it is worth rethinking resizeControl (and resizeStack / moveStack) - if you set the rect of a control directly, you'd end up getting two messages not one where a single message with the changed rect would probably be easier to deal with.

[monte]

Hmm... the reason I was thinking of a separate message was to avoid running resizeControl scripts when you didn't need to. A normal LC object doesn't need to change anything if just moved.

[monte]

Should these messages only be sent if the control is open? I've got it working... took me a while to realise that I needed to change the size of hashandlers because it was at it's limit... I'm just working on sending the message during a group scroll. From the looks of things group scroll handled conditionally on whether the scroll is different to the current value... should I change that?

Also I'm not sure if I need to add control states for these messages to guard against recursion. I guess there could be recursion if someone moved a control in a controlMoved message or someone changed the visibility of a control in a visibilityChanged message but it seems to me much less likely to happen than with resizeControl and group rects.

[monte]

I've submitted this just for feedback at this stage:
https://github.com/runrev/livecode/pull/368

[LCMark]

At the moment I think resizeControl gets set regardless of open state... However, I wonder if that is 'correct' - we could make it so that these messages are only sent between openControl and closeControl (although there might be an issue for export snapshot here). In any case, I think the messages should be only sent if the relevant aspect has changed - i.e. controlMoved if x,y of rect has changed, and visibilityChanged if the effective visible of the control has changed.

In terms of naming (for consistencies sack), I wonder if it should be moveControl, and (maybe) displayControl or showControl. It would keep them in the same sort of namespace *control, and given its the effective visibility of the control that matters it would separate the idea of the visible property of the control from the message.

In terms of recursion then, yes these messages do need to check for it - just because it is 'unlikely', does not mean it won't happen (even by accident). Also, it means the messages can be used for constraint - if moveControl moves the control somewhere it doesn't like, the control can happily move itself to where it wants to be just by resetting the rect (similar for the visible notification).

[monte]

OK, I'll look at making these changes when I get a chance.

[monte]

There's no options left for layer control states... do I need to change state to uint64_t or should we add a uint16_t messagestate for resizeControl, moveControl, showControl, hideControl. It could just use the the hashandler flags. That way all conditional messages get the same treatment as part of conditionalmessage...

[LCMark]

Hmmm - I think having a separate field using the same bits as 'hashandlers' makes sounds like a good plan - it would mean none of these messages would be re-entrant (on a per-object basis) which I think is the proper behavior and makes the code neater too

[monte]

OK, I've done this but now I've noticed an issue where moveControl is sent multiple times because of resizeparent. I'll see what I can do to work around that. Luckily my test case was a group wrapping a locked group otherwise I wouldn't have seen it.

[monte]

OK, I think I've got this implemented however I've now noticed a quirk that occurs for resizeControl too. The quirk is parents that get resized as a result of the resizing or moving of a child control don't get sent the message.