controlIDs|Names of group

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Thu Apr 25, 2013 12:03 am

Cool. Originally I was thinking controlIDs but childControlIDs seemed to be clearer... also the number of controls and the number of lines of the controlIDs should return the same number. I guess it would be clear if I implemented controlIDs and childControlIDs so there was an obvious difference. Hmm... I don't know why I didn't think of implementing this for cards too...

If it were implemented for cards should sharedGroups be included? I usually iterate over them separately to ensure sharedGroups are only parsed once.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Mon Apr 29, 2013 1:12 pm

The 'the childControlIds of group ...' seems like a worthy addition to me - as does 'the childControlIds of card ...' (hint hint ;)).

In terms of naming then it is important to remember that the current action of 'control ...' when searching is to recurse through all controls - whether in groups or not. Thus distinguishing between 'the controlIds' and 'the childControlIds' is important - in particular, the 'child' variants don't recurse (in the modern world, of course, this seems slightly backward - however the current semantics of control searching isn't something that can be realistically changed at this time as it is what everybody is used to).

Of course, ideally at some point we'll have something like:

Code: Select all

repeat for each [ child ] control [ id ] <var> in <object> [ where <expr> ]
...
end repeat
However, adding that is significantly more involved than the properties...

P.S. 'the selectGroupedControls of group ...' is intended as something to purely affect selection - it shouldn't have any effect on script.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Mon Apr 29, 2013 1:19 pm

Great runrevmark... now that I know you are keen I'll implement the rest of it. Yes, I was thinking childControlIDs of cards also controlIDs and controlNames of both group and card. Should be able to have most of the code in common for controlIDs and childControlIDs ... just turn on the recursive bit when it's controlIDs... it's a pity there isn't a container class between control and group/card so we could implement this kind of thing in one place...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Mon Apr 29, 2013 1:56 pm

Ahh - yes - the lack of a 'container' abstraction has always irked me slightly also... However, pragmatically, cards are a different sort of container from groups - cards only hold a list of references to objects (MCObjptr's), where as groups hold a list of objects (MCObject's). This distinction is to handle the ability to have shared groups amongst cards.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Mon Apr 29, 2013 2:08 pm

OK... I'd seen MCObjptr but hadn't looked into it...So... I guess the code might not be as similar as I thought
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: controlIDs|Names of group

Post by mwieder » Mon Apr 29, 2013 5:33 pm

I hadn't looked into that either. I take it, then, that an MCObjPtr isn't a handle to an MCObject?

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Mon Apr 29, 2013 11:44 pm

It seems to be a list to put controls in where you can give them a different parent... While an MCControl can only have one parent multiple cards could have the same MCControl in the MCObjPtr with the different cards as the parent. Kind of makes me wonder if we could have shared controls that aren't in groups but not sure if we ant to bother going there...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Tue Apr 30, 2013 12:58 am

I've had a look at card and I noticed groupIDs which jogged my memory that there is a precedent for returning just the childIDs in a property like this. Makes me wonder if it shouldn't just be controlIDs rather than childControlIDs but I'm happy either way and also happy to implement both.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: controlIDs|Names of group

Post by mwieder » Tue Apr 30, 2013 1:28 am

I realize the "child" nomenclature was my idea in the first place, but it seems to work the opposite from the way I'd intuitively expect it to work, i.e., "the childControls" of a group should, I think, return all the controls in the group and "the controls" of the group should return the first-level children. Given that the current situation isn't going to change without breaking most every stack out there, I'm good with either "controlIDs" or "childControlIDs". The "controlIDs" seems more in line with the "groupIDs", so I guess that makes more sense. I really want something that says "hey... these are only your immediate family", but I can't think of a good natural language way to name that.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Tue Apr 30, 2013 8:47 am

I've actually implemented both controlIDs and childControlIDs although I only really want childControlIDs it was another 5 minutes work to do them both... I'm happy to reverse the names so it's the childControlIDs that recurses through the tree.

Now the big question is whether sharedGroups should be returned in the childControlIDs of a card... I'm hoping I can get away with not including them although the current implementation does include them. That will save me from having to check if a group is shared before parsing it because shared groups need to be handled separately so they aren't parsed multiple times.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Tue Apr 30, 2013 10:08 am

I think it needs to be 'childControl*' for only the immediate children... The reason here is that people currently understand 'control' as recursing, thus 'child control' would restrict to just immediate children (not an ideal situation, granted, but one we have inherited - for now).

In regards to shared groups - then, yes, they should be included since from that context they are immediate children (and controls). You can easily check if a group is shared though - if it has 'sharedBehavior' true, then it could be on more than one card, and if it is the cardIds of it (which is pending integration :)) will have more than one line. Alternatively, you can use the 'sharedGroupIds' of a card then filter whilst processing the childControlIds list.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: controlIDs|Names of group

Post by monte » Tue Apr 30, 2013 10:23 am

I think it needs to be 'childControl*' for only the immediate children... The reason here is that people currently understand 'control' as recursing, thus 'child control' would restrict to just immediate children (not an ideal situation, granted, but one we have inherited - for now).
Right... that's what I've done then. Pushed the card change and added controlIDs|Names too this morning.
In regards to shared groups - then, yes, they should be included since from that context they are immediate children (and controls). You can easily check if a group is shared though - if it has 'sharedBehavior' true, then it could be on more than one card, and if it is the cardIds of it (which is pending integration ) will have more than one line. Alternatively, you can use the 'sharedGroupIds' of a card then filter whilst processing the childControlIds list.
Hmm... well the sharedBehavior can currently be true on a nested group which is why I sent that other pull request. Even if that's fixed we can no longer rely on it unless when the stackfile loads nested groups get their sharedBehavior set correctly...

The sharedGroupIDs of the card is reliable though... are you sure I can't interest you in unsharedChildControls of card ;-)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Tue Apr 30, 2013 10:28 am

Hmm... well the sharedBehavior can currently be true on a nested group which is why I sent that other pull request. Even if that's fixed we can no longer rely on it unless when the stackfile loads nested groups get their sharedBehavior set correctly...
Ah - indeed - I just found the comment on MCStack::checksharedgroups() about how it never unsets it... I'll have to try and remember why I didn't make it more draconian.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Tue Apr 30, 2013 12:00 pm

Reviewed the code for MCStack::checksharedgroups()... It only iterates over top-level groups and ensures that any that should have the 'shared' bit set do, in fact, have the shared bit set. Its purpose is to ensure that any (top-level) group that is placed on more than one card does have this bit set. It should be a simple matter to enforce nested groups not having this bit set - I'll file a bug about it and see what we can do.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: controlIDs|Names of group

Post by LCMark » Tue Apr 30, 2013 1:40 pm

Ack - looks like I managed to thoroughly confuse myself with this one (mainly by not reading more closely!)... For some reason I though 'controlIds' existed already for some object (card?) hence my vehemence that the immediate children search should be childControlIds. Sorry about that :S

So, just to reiterate the argument (so I can clarify it in my own mind as much as anything else!)...

At the moment doing 'control id x of ...' will cause a fully recursive search of the card (or group) for said control. Thus when we add 'repeat for each control id ...', it should probably do the same otherwise you have a difference in interpretation of what 'control id x' means in two different contexts. Now my thinking on this was (at some point) we could add a 'child' adjective to control chunks so: 'child control id x of' ... would be like 'repeat for each child control id x of ...' and only search immediate children. This resulted in my jumping on the 'childControlIds' band-wagon as it gives the following 'nice' equivalence:

Code: Select all

repeat for each [ child ] control id x of tObject
    ... do stuff with x ...
end repeat
is the same as:

Code: Select all

repeat for each line x in the [child]controlIds of tObject
   ... do stuff with x ...
end repeat
Which is the same equivalence as you have with 'repeat for each key x of ' and 'repeat for each line x in the keys of'.

This is all well and good - except that 'controlIds' doesn't yet exist, and 'groupIds' (the example mwieder gives) only returns the top-level groups of a card i.e. only immediate children. So by introducing 'childControlIds' there is a non-uniformity between that and 'groupIds'.

So it seems we have two options:

1) Have 'childControlIds' be immediate children only : giving consistency with the idea of 'control' chunks being all descendents (and, in the future, the same as 'child control' chunk) but break consistency with 'groupIds of card'.

2) Forget about 'childControlIds' and make controlIds only return immediate children : breaking consistency with the idea of 'control' chunks being all descendents, but keeping consistency with 'groupIds' of card'.

One option to mitigate this perhaps is to (in the future) consider a context-local property that controls how far the search goes (e.g. the searchDescendents). If this is true, the 'control' would be its current behavior, if false it would be the child-only behavior. We could then have adjectives 'child' and 'descendent' to override it. This could even work with properties 'the groupIds' / 'the controlIds' would use the state of the flag; 'the childControlIds' would override.

[ Incidentally, I am thinking quite far ahead here as when we get the new syntax parser, property names will be able to be things like - the [ child | descendent ] control ids - thus we won't descend too far into multi-word-camel-case-property-name-hell ].

[ Another incidentally, I think the whole 'search descendent control' behavior actually stems from the idea of backgrounds which is inherited from HyperCard. i.e. The idea that the controls in a background placed on a card are in some sense 'unified' with those on the card and thus you shouldn't have to reference them as children of the background. As groups were/are an extension of this it was probably never considered that when being used as a non-background they should (perhaps) not have this behavior. ]

Locked

Return to “Engine Contributors”