controlIDs|Names of group

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2826
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 6:23 pm

multi-word-camel-case-property-name-hell
Don't want to get into too-many-dashes-hell either :P
Or so.many.dots.you.can't.find.your.way.home hell, for that matter.

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

Re: controlIDs|Names of group

Post by LCMark » Tue Apr 30, 2013 6:26 pm

@mwieder: lol - with hindsight it probably should have been multiWordCamelCasePropertyNameHell - probably would have illustrated my point better ;)

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2826
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 6:29 pm

Another option (I don't particularly like it, but I think it should be mentioned) is something like the way the xml parser specifies child nodes. So we'd end up with

Code: Select all

get the controlIDs(1) of group "xyzzy"
to get just the first-level child controls or one of

Code: Select all

get the controlIDs(-1) of group "xyzzy"
get the controlIDs of group "xyzzy"
to get the whole set. That wouldn't change the current behavior and has a minimum impact on the parser without introducing a new vocabulary.

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

Re: controlIDs|Names of group

Post by monte » Tue Apr 30, 2013 9:26 pm

Well I'm easy either way as long as we get the property. The main problem I see with using controlIDs for a non-recursive list is it mains it will be virtually impossible to come up with a name for a property to return the full list like the number of controls. I think given none on the current IDs|Names properties recurse there's a precedent there. Having both might be useful (which is what I've done).. in some cases you just want to loop over all the controls and don't care if some are in a group or not.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by LCMark » Wed May 01, 2013 1:43 pm

I think the safest course of action is to go with 'childControl*' for the non-recursive versions. It allows the most future flexibility - we can always deprecate that property or make it a synonym for something else sometime down the line. (I think we can live with the 'slight' discontinuity of 'groupIds' for now - it is essentially meant to be akin to 'sharedGroupIds' and 'backgroundIds' which don't recurse since only top-level groups are relevant so there's an element of consistency there).

Anyway, I'm going to go ahead and merge in Monte's pull-request :)

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

Re: controlIDs|Names of group

Post by monte » Wed May 01, 2013 11:57 pm

Great... and you're sure I can't interest you in the unsharedChildControlIDs of card?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by mwieder » Thu May 02, 2013 12:47 am

Shouldnt that be Card.Controls.Child.Unshared.IDs ? :shock:

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

Re: controlIDs|Names of group

Post by monte » Thu May 02, 2013 1:31 am

lol... yeah, I know it's a ridiculous name but I'd really like to be able to recursively parse a stackfile without having to check if a group id is among the lines of the sharedGroupIDs of the card...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by LCMark » Thu May 02, 2013 10:23 am

Hmmm - can't you just derive this information easily enough from the groupIds and the sharedGroupIds... A group is unshared if its in the groupIds of the card, but not in the sharedGroupIds. Indeed, this creates the list for you:

Code: Select all

local tUnsharedGroupIds, tSharedGroupIds
put the groupIds of this card into tUnsharedGroupIds
put the sharedGroupIds of this card into tSharedGroupIds
split tUnsharedGroupIds by return as set
split tSharedGroupIds by return as set
repeat for each key tKey in tSharedGroupIds
    delete variable tUnsharedGroupIds[tKey]
end repeat

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

Re: controlIDs|Names of group

Post by monte » Thu May 02, 2013 10:49 am

Sure we can get it multiple ways... like we can with the childControlIDs etc but it occurs to me that when you want to iterate all the controls in a stack you want to do it as fast as possible so anything we can do to speed that up is a help. Something as fundamental as recursively iterating a stack should be supported at engine level in my opinion and right now you can't ensure you only parse each control once unless you check for shared groups...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by mwieder » Thu May 02, 2013 5:43 pm

@Monte- I'm not sure I agree with this. Iterating through the lists isn't something that would normally be done except when working in the IDE (although I'm sure there are some edge cases you could come up with), and I don't see that as rating a push into the engine. Normally I'm all for speeding things up, but I think the minimal speedup doesn't warrant the added complexity of adding a new keyword into the engine. The scripted solution seems to fill the need - if that weren't possible then things would be different.

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

Re: controlIDs|Names of group

Post by monte » Fri Oct 04, 2013 12:57 am

I would like to document that controlIDs, childControlIDs, sharedGroupIDs, cardIDs and their name counterparts all return the list in layer order so that the feature can be relied upon in future implementations. I'm relying on this in lcVCS. Is everyone agreeable to that?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by mwieder » Fri Oct 04, 2013 1:23 am

Sounds good to me. The lists can be sorted into numeric or alphabetic order if necessary.
It does bring up a slight conundrum, though, in that the list can't be sorted back to layer order, but I don't see that as a stumbling block.

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

Re: controlIDs|Names of group

Post by monte » Fri Oct 04, 2013 1:40 am

I'm not sure why you would want to sort them or if you did why you would want to sort them back ;-)

I suspect it's always going to be simpler to return them in layer order because layer is represented by the linked list of controls but as its not documented I don't like relying on it.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: controlIDs|Names of group

Post by LCMark » Fri Oct 04, 2013 8:55 am

@monte: I think it is reasonable to specify that these lists will be in layer order - indeed, the 'number' / 'layer' property the engine can return is calculated by stepping through the linked-lists in these cases. Even if the internal data structure changed in some fashion that meant this wasn't the case there would still need to be an iterator of some sort to step through them in layer order for rendering (and searching!) purposes.

@mwieder: You can still sort them back:

Code: Select all

put the cardIds of this stack into tCardIds
sort the lines of tCardIds by random(1000000)
sort the lines of tCardIds by the number of card id each of this stack

Post Reply

Return to “Engine Contributors”