Add pref for renaming behiors

Something you want to see in a LiveCode product? Want a new forum set up for a specific topic? Talk about it here.

Moderators: heatherlaine, Klaus, FourthWorld, robinmiller, kevinmiller

bogs
Posts: 2279
Joined: Sat Feb 25, 2017 10:45 pm

Re: Add pref for renaming behiors

Post by bogs » Sat Aug 04, 2018 2:35 pm

Jim Mac wrote:
Sat Aug 04, 2018 7:15 am
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.
Jim Mac wrote: 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.
Image

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

Re: Add pref for renaming behiors

Post by mwieder » Tue Aug 07, 2018 10:40 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 22
Joined: Wed Jun 28, 2006 9:22 pm

Re: Add pref for renaming behiors

Post by Jim Mac » Wed Aug 08, 2018 4:11 am

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
Posts: 2279
Joined: Sat Feb 25, 2017 10:45 pm

Re: Add pref for renaming behiors

Post by bogs » Wed Aug 08, 2018 5:11 am

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 -
Jim Mac wrote:
Wed Aug 08, 2018 4:11 am
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.
Last edited by bogs on Thu Aug 16, 2018 9:37 pm, edited 1 time in total.
Image

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5569
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Add pref for renaming behiors

Post by dunbarx » Thu Aug 16, 2018 6:10 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6173
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Add pref for renaming behiors

Post by FourthWorld » Thu Aug 16, 2018 6:20 pm

dunbarx wrote:
Thu Aug 16, 2018 6:10 pm
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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5569
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Add pref for renaming behiors

Post by dunbarx » Thu Aug 16, 2018 8:25 pm

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

Post Reply

Return to “Feature Requests”