LiveCode Forums.

Hi

I recently implemented cardIDs of group to match cardNames seeing as I never understood why it didn't exist. Anyway, the pull request is in for that but I'm thinking better ways to iterate controls would be useful. What ways can people think up to iterate controls?

A simple addition would be controlIDs|Names of group which would return the direct descendent children of the group.

But I wonder if there's some optimised way we could be doing this like specialised repeat loops designed for iterating controls.

Cheers

Monte

I would love something like

repeat for each control theControl of group / card

Repeat for each "control" would be nice. So would "for each button", etc. Right now you can say "the number of controls of group x" but you have to iterate from that result.

The"<whatever> of group <xyz>" would be nice syntax to have in general use. It's the other side of "the owner of".

I was thinking that "the children of group x" would be good syntax, but I changed my mind because I think "the children of" might be better syntax for inheritance, to match "parent" scripts, i.e., list the objects that are subclasses of this object.

I like repeat for each control too. If theControl was somehow a pointer to a pre-parsed control reference rather than a long ID or something I think it would be faster than what we can currently do. I almost always iterate controls recursively so I'd like to just iterate the child controls. Mark's children syntax is nice. But I guess it could also be repeat for each child control as an extension of repeat for each control...

"repeat for each child control of group x" seems redundant to me. "repeat for each control of group x" would do the same thing, no?

The problem with just doing a 'repeat for each control' is that there could be a lot of controls on a card (think of a big data grid or whatever) and looping across them all (possibly multiple times) just to check if some have names that match something seems a bit over the top.

Filtering down the results to loop over to certain types, or children of a group, or even ones that match a name 'prefix' would allow a finer definition for actions on those results. There are probably a whole pile of other types of filtering that could be applied to make a reduction in the livecode side of things and make the language even more intuitive.

Just my 1.768 pence/cents worth

In all cases though, a 'repeat for each control q' type command would get my 100% vote

PS. Is it feasible/sensible/allowable to have the "repeat for each line x in foo" to accept the word "of" in place of the "in"? As in so that LC doesn't care which is used I always get it mixed up and have a little red blob when hitting apply

Dave-

the proposal here is for "the controls of group x" or "the controls of card x", so the scope is limited by the command syntax. I just filed a bug on "the number of controls of" not respecting the state of selectGroupedControls, and closing that loophole should cut down on the number of iterations.

PS. Is it feasible/sensible/allowable to have the "repeat for each line x in foo" to accept the word "of" in place of the "in"? As in so that LC doesn't care which is used I always get it mixed up and have a little red blob when hitting apply

Hah! Yes, I'm always getting tripped up by that as well.

It doesn't look complicated at all to allow of as well as in in repeat for. I always do that too... Maybe start a new thread on this. I'm happy to implement it but runrevmark may not want it.

@mwieder hmm... are you saying if selectGroupedControls is false the number of controls should return 1 for a group? I'm not sure I like that. Could break lots of code.

Yes, that's what I'm saying. I think the intent of selectGroupedControls=false is to treat the group as a single control. You could argue the point that it should mean one thing at the IDE level and another in a script. However, given the fact that you can set it to true in order to get the inner control count, and that there's no way to do the opposite (treat the grouped controls as a set at script level) I think it's a valid thing to want. I think of it as being of a type with the "private" keyword for handlers: there are things you want to encapsulate and others you want to publish. And the intent of setting selectGroupedControls is to encapsulate the grouped controls in order to treat them as a single entity.

I've just sent in a pull requst for childControlIDs|Names of group. I thought this name more clearly made the point that it's just the children we are getting not all controls in the group. Wouldn't be complicated to add controlIDs|Names too... would use most of the same code but will wait for runrevmark to comment...

OK - I must have missed something here. Are there controls in a group that are not "child controls"? Are you referring to just first-level children?

Yes, just the first level. It's equivalent to sharedGroupIDs or cardIDs of a stack and makes it easier to recursively iterate through a stack. Possibly needs a better name though based on your question?

In that case it's the same thing I wanted with selectGroupedControls. It wasn't clear to me that that was the case, and it's probably a better solution. I can't at the moment think of a better name.

It's not quite the same as your selectGrouedControls change because that would return all controls in the group apart from those in a group with selectGroupedControls false. This is only the direct children so all controls of direct child groups would not be returned regardless of the state of selectGroupedControls. Basically I'm trying to avoid (when I want to recursively iterate through controls) having to jump through hoops to deal with groups because I can't easily get a list of direct child controls. Having to iterate through all controls in a group only to find the ids of the direct children is crazy when this property took all of 15 minutes to implement.

Monte- what I meant is that the end result you're seeking is the same one I was seeking. I like your approach to this (if we can get the naming worked out ) and it doesn't mess with any existing functionality of selectGroupedControls.