Cards controls loop?

[dunbarx]

My handler does subStacks, and if expanded to include groups and "subGroups" should work just fine. At least it gives a roadmap.

Craig

[dunbarx]

If one is trying to create a large group from some existing groups, and sets even one of their "sharedBehavior" to "true", it is no longer possible to create a new group that includes it. I only mention this for information.

Craig

[dunbarx]

I am trying to get my head around the issue that was raised of shared and/or background objects.

It seems to me that if one is only trying to access all possible scripts in a stack it does not matter how the groups within that stack are arranged, or who belongs to whom. The number of groups is fixed by, er, the number of groups. So if one travels through the scripts of all controls on all cards (and I mean ALL, including substacks) , and then through all groups on all cards, and then through all card and stack/substack scripts, what is left out?

In other words, what does the "status" of any particular group matter? How would a group of any kind escape a loop that queries "the number of groups"?

I so love taking about LC.

Craig

[bn]

I am trying to get my head around the issue that was raised of shared and/or background objects.

It seems to me that if one is only trying to access all possible scripts in a stack it does not matter how the groups within that stack are arranged, or who belongs to whom. The number of groups is fixed by, er, the number of groups. So if one travels through the scripts of all controls on all cards ( and I mean ALL, including substacks) , and then through all groups on all cards, and then through all card and stack scripts, what is left out? In other words, what does the "status" of any particular group matter?

Craig

Craig,

If you iterate the controls of a card and there is a group with the backgroundBehavior set to true then that group is potentially on each card but the scripts of that group are the same on all cards. That means you get a lot of duplicates when searching for text in the scripts of all controls.

One way to avoid that is to stuff the result of your search into an array with a key that is the identifier of a control/group. That way you only get the results only once.

Kind regards
Bernd

[dunbarx]

Bernd.

OK, the issue is duplication, not that some scripts would be missed. That I get. Thank you.

Craig

[FourthWorld]

Checking for duplicates will not be slow, and even faster if gathering into an array rather than a string. I've stress-tested routines like this in projects with many thousands of objects. You will like the results. LC stacks are loaded into memory when anything in them is touched, and the internal organization makes the efficient to traverse.

But I'm still wondering, and forgive me if this was addressed earlier: what isn't working in the IDE's tool built for this purpose?

[dunbarx]

Richard.

what isn't working in the IDE's tool built for this purpose?

What? What tool?

Craig

[richmond62]

The one I mentioned!

[Zax]

But I'm still wondering, and forgive me if this was addressed earlier: what isn't working in the IDE's tool built for this purpose?

For several reasons.

• In my LC 9.x Indy, the UI doesn't return the number of found occurences.
• The built-in "Find" UI is too complicated for my needs : I always want to search inside script and not text containers, and always in the current stack and its substacks. So I have created a small dev tools for my needs.
• I would like an "engine" to retrieve all controls that I can use for other tasks. For example store controls size and position.

But you're right: traversing all controls isn't slow at all

Thanks Bernd for the new version of your stack. I will look at the code, seems very interesting.

[dunbarx]

Jax.

You can turn off field text in the "Find..." menuItem.

Richard.

Oh, that one.

Craig

[dunbarx]

Richmond.

Indeed you did. Sometimes I do not see the forest...

In my defense, the trees were so enticing.

Craig

[FourthWorld]

I would like an "engine" to retrieve all controls that I can use for other tasks. For example store controls size and position.

I daydream about something as concise and powerful as CSS selectors, it at very least as simply powerful as XML queries.

I started down the road if a generalized "with each" sort of handler, where you pass in a container (stack, card, group) and scoping specifiers for elements to be affected and the changes to apply, and off it goes.

But in the moment it was easier to write a fixed loop and move on to other tasks.

As the LC audience grows I may be better able to justify the investment in generalization.

In the meantime, there's always Bernd. Thank you, Bernd.

[richmond62]

Richmond.

Indeed you did. Sometimes I do not see the forest...

In my defense, the trees were so enticing.

Craig

No, that is not the problem: the problem is two-fold:

1. People round these parts, being 'clever', 'experienced', 'full-time', 'computer programmers' believe that Richmond is some daft hobbyist who specialises in antagonising people and getting things wrong. Of course that is partly true.

2, As a result of #1 they look for fancy, complicated solutions, overlooking several useful 'spades', 'shovels, and 'screwdrivers' that have been in the MC/LC toolshed a very long time and can often do the job in a very straightforward manner: while Richmond almost lives in that toolshed for the simple reason that he's essentially a lazy slob who always looks for the easiest way to do something.

Join me in the toolshed.

Or, to use a different set of terms: why not come back into the closet? ROFL.

[Zax]

You can turn off field text in the "Find..." menuItem.

Yes, I had noticed the different options of the Find Dialog but:
1 - as far as I know, no options allow to display the number of found occurrences
2 - my idea is to be able to recycle the function that lists all the controls to use it in other cases (storing the positions and sizes of the controls for example).

Anyway, looping through the controls and checking for duplicates for the "background" groups is fast enough.

@Richmond: I love LC so much that it's a real pleasure to program lots of small stacks, even if I'll never use most of them

[bn]

.....
In the meantime, there's always Bernd. Thank you, Bernd.

Hi Richard,

Thank you. But I learned from the advanced users of the list and this forum.
Jacque, you and others. So I thank you all.

Kind regards
Bernd