Add pref for renaming behiors

[bogs]

In the short term, I have my work around. Others will read about the issue and deal with it their own way. Done with discussion?

Probably not done with the discussion

I realize you are the OP of the request, and that your satisfied with being done with it, but once you put in a statement, you find others who are thrilled with the idea (or not), and others still who may actually implement something from it, or improve on work arounds that have come from it.

I don't really have a stick in the fire here (I don't use behaviors per se), but your last post did have a statement I am curious about.

In hindsight, changing the name of a stack should be expected to break things inside the stack?

I haven't had anything break on changing either the internal or file name of a stack, but my projects are relatively simple (fewer than 3 stacks).

Under which circumstances would you find that other than behaviors? Is this something you expect from say, something that changed in the newer IDEs (8.x up)?

The reason I ask is because I program mostly in the (far older) series of IDEs, and *have not encountered a situation where renaming the stack would have any ill effect. If there were a particular point where these ill effects outside of behaviors occurs, it would be good general knowledge I think.

*Not claiming I have seen every situation possible, and only having used Lc about a year, not multiple decades.

[mwieder]

Craig-

Back in the day, a stack ID was immutable. This might resolve the whole issue, if the behavior pathname referenced the stack ID instead of the stack name.

Unfortunately no. The stack ID has always (IIRC) been the next available ID for object creation, and thus a moving target.

[Jim Mac]

bogs - As far as I know, the problem will only arise with behaviors and therefore only in LC8+.

I love them and use them as a convenience when I have lots of controls that need to do exactly the same thing.

I create a control and assign it a behavior from a dropdown menu that shows all the available buttons... with their simple button names ( e.g. button "Check Dates"). If I select that one... close the property inspector and come back.. the behavior will have been assigned to <button ID 1588 of stack "My Stack">. The fact that the stackname is part of the behavior assignment is hidden when you're assigning it.
(Maybe this points to a possible solution.... change the behavior assignment dropdown to include the stack name... making it apparent it might be connected to the stack name?)

If I change the stack name in the property inspector to "My Stack V1" for some reason (which I won't be repeating), the behavior stays assigned to stack "My Stack" which no longer exists. Not finding the behavior, the app fails gracefully by not doing anything when that behavior is invoked.

[bogs]

I find that a very good and detailed explanation. Jacque and I had a discussion about behaviors a while back in a different post, as I said earlier I myself don't use them, she does and is a big fan of them, as are many others here, and I can understand why.

I think what you said here -

Maybe this points to a possible solution.... change the behavior assignment dropdown to include the stack name... making it apparent it might be connected to the stack name?

is something worth serious consideration, as it doesn't seem (on the face of it) that it would be hard to implement. Maybe as a twist, such a dropdown would allow you to reassign the behaviors if you changed the stackname as well? Certainly it should be possible, I would think.

[dunbarx]

Richard.

Just remembered this thread.

AFAIK the ID property of stacks was always used as a placeholder for the next available ID for the objects within it.

As with HyperCard, SuperCard, Toolbook, and others, the identifier for a stack is its name.

Been a while, but it turns out that HC stacks do not have an ID property at all. Only windows do. Asking for the id of a stack throws an error. You have to ask for the id of the card window. In any case, that id is permanent, and does not depend on the number of cards or the makeup of controls on any card.

Craig

[FourthWorld]

Been a while, but it turns out that HC stacks do not have an ID property at all. Only windows do. Asking for the id of a stack throws an error. You have to ask for the id of the card window. In any case, that id is permanent, and does not depend on the number of cards or the makeup of controls on any card.

What happens if I give you a stack that has the same ID as one you're working on?

Merely having an integer value like that would seem to pose no problem. But attempting to use would seem very problematic: Without a more complex UUID-like scheme, chaos ensues.

LC has a windowID property, but not for the purpose of attempting a universal identifier. Instead, it's an integer representation of the pointer to the record of the window structure, not needed much in LC Script but very useful in externals and perhaps even LCB when you need to access the rendering port for the window's content region.

[dunbarx]

What happens if I give you a stack that has the same ID as one you're working on?

Easy in LC. Just make a few new stacks. They will all have the same id. If you add the same number of controls to each, they will all have the same id.

I think it would be very useful indeed to have an immutable stack id property. How this might survive between sessions is a point to consider since LC should not be required to remember which stack had which id from last month.

Some may say this is moot since one can assign a custom property to accomplish the same end, the uniqueness of that property being better left to the author. The problem with that is that you cannot:

Code: Select all

go stack theOneWithTheParticularCustomPropISpecify

Craig