Control Array

[Perry]

I'm coming from VB6 so I have to rethink some conventions that I'm used to. VB controls can be made as control arrays. For instance they can be referred to as controlname(x).. Button(x) ... or Image(x). This has the potential to shorten code considerably, because they would use the same handler but could be referred to by key or index. Is there some similar device in LC?

[FourthWorld]

Yep - you can refer to controls by the ordinal number according to type (e.g. "button 4") or generically for all controls (e.g. "control 8").

[dunbarx]

Hi.

What Richard said. And do not forget by name.

And also by a property known as the "id" which never changes (for controls). This is very useful if changes to names or layer number are made to controls, since they provide absolute references. Note there are more "xTalk" references, such as "first, "last" and others, which can come in real handy in certain situations.

Craig Newman

[Simon]

Ok my addition...
What Richard and Craig say.
Now maybe it's clear coming from VB but hasn't been stated here yet.
The controls get their ordinal numbers from the layer that they are in, button 4 is the fourth button from the bottom (not the fourth control). Image 1 is in the lowest layered image (yet actually be in layer 25 of the card).

Simon

[jacque]

And also by a property known as the "id" which never changes (for controls).

Unless you change the ID yourself. The ability to alter the ID of any object was introduced to solve some other issues, but I think it throws a wrench into what used to be an absolutely reliable reference.

But you're right that if the stack author doesn't change the default IDs, then they act as before and never change on their own.

[Klaus]

Yep, but nothing will ever beat a CLEVER naming convention!

[dunbarx]

Jacque.

I had heard this was now modifiable. Say it ain't so. I suppose if I stick to my old guns it will still work like always. I can easily be that stubborn and obtuse.

Any talk or consensus about why this was done? Just for the sake of more flexibility? Sounds good, feels bad.

Craig

[jacque]

Something about the debugger Mark Wieder was working on, I think. But I'm vague about the reason. It started out innocently enough; for the last few years you've been able to change the ID of images, and only images, in order to prevent ID conflicts. That seemed reasonable to me. Within the last year or so it was altered to allow changing the ID of any object. That doesn't seem so reasonable to me, but who am I.

But yeah, if you don't touch it, it acts like we're used to. On the other hand, I've taken to setting the IDs of all my images to high numbers, just to avoid potential conflicts with the IDE icons and such. I usually number them above 50,000.

[dunbarx]

Jacque.

Then you have to keep an index of image id's.

Great.

LC cannot tell that whatever id it assigns to an image might conflict with a native icon id? I rarely deal with these sorts of objects, like images, audio files and the like.

Say it ain't so.

Craig

[FourthWorld]

I'll say it: "It ain't so."

Or at least I don't think it's so, though I'm not entirely certain of the nature of your concern.

LC looks for images in a fairly logical path that generally works out quite well for almost every need. If not, we'd be hearing screams on the use-list daily, but thankfully we don't.

The very detailed notes in the Dictionary entry for ID describe this, and also note the ID ranges the IDE uses internally for those who may have special needs outside of how the engine looks for images.

[dunbarx]

Richard.

Understood.

i was really bristling at the fact that now ALL controls have a settable id. Just old-fashioned, but I hate that.

Craig

[jacque]

Well, you don't need to keep an index of image IDs unless you've hard-coded original IDs and then change them dynamically in a script somewhere. Once you've set the ID yourself, it isn't any different than if the engine sets it. Typically I set an ID immediately after I import an image, and I only need to do that on the first one. That changes the ID of the stack automatically, which in turn controls the IDs of all subsequent imports, so they all acquire high-numbered IDs after that.

I almost never refer directly to an ID in a script any more. If I need the ID, I reference it indirectly by name:

set the icon of btn 1 to the ID of image "iconImg.png"