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: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

Jim Mac
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 28
Joined: Wed Jun 28, 2006 9:22 pm

Add pref for renaming behiors

Post by Jim Mac » Thu Aug 02, 2018 12:25 am

I just ran into the issue of behavior references not updating on stack rename. The discussion in the "Method to rename stack "(http://forums.livecode.com/viewtopic.php?f=8&t=31136) thread in the "‹Getting Started with LiveCode - Experienced Developers" forum provided the work around I needed... scanning all cards for controls with behaviors that had the old stack name and replacing that with the short name of the current stack but....
Saving a stack with a new name should NOT break the stack.

I envision a simple scan of a stack to identify that there are behaviors in controls that could break with a stack name change and a warning dialog to ask if behaviors should be adjusted to the new stack name or not on save. Thoughts?

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

Re: Add pref for renaming behiors

Post by bogs » Thu Aug 02, 2018 2:47 am

I myself don't use them enough to comment effectively here, but lots of others do. I could see it being useful.
Image

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3273
Joined: Sun Jan 07, 2007 9:12 pm
Location: Bochum, Germany

Re: Add pref for renaming behiors

Post by bn » Thu Aug 02, 2018 2:16 pm

Hi Jim,

as outlined in the link to the forum you posted it is probably not possible to reassign the behaviors when you rename the stack where the behavior buttons live.

In addition to the problems mentioned in the other thread you mentioned there is the problem of nested behaviors which can consist of a mix of behaviors from the "stack to be renamed" and other stacks. Not to mention script-only stacks. No way to know for the engine what is what. After all the behvior is

button id "theID" of stack "nameOfStack"

What you could do and which works for me in testing is to make a substack of your stack "stackWhichNameChanges". Give the substack a fairly unique name to avoid a name space clash e.g. append the milliseconds as the datagrid does. Then populate the substack with the behaviors you want to use in your mainstack / further substacks.

Now you can rename the main stack as long as you want and have no trouble from renaming as far as the behaviors of the main stack / further substacks is concerned.

Please also have a look at the dictionary entry regarding "behavior".

Kind regards
Bernd

capellan
Posts: 607
Joined: Wed Aug 15, 2007 11:09 pm
Contact:

Re: Add pref for renaming behiors

Post by capellan » Thu Aug 02, 2018 9:26 pm

This is a real problem. Ideally, renaming a stack or a control should not break
scripts or behaviors. How could we avoid (or solve) this problem?

Maybe we could request a new (and optional) constrain to LiveCode IDE.

This new constrain is that developers could not change stack's names,
only their labels. (Remember, we could not use stack's id because a stack id
is the id of most recent control so it's not a permanent value).

LiveCode IDE could create a stack's name from an UUID function
http://livecode.wikia.com/wiki/Uuid like this:

Code: Select all

set the name of this stack to uuid("random")
The new and non modifiable stack name is, for example:
b471de8f-4cc6-445f-909e-252e574fed5f

or the developer could choose to create stack names from a combination
of values (like hard disk serial, mac Address, stack's creation time, etc...)

This new constrain could replace automatically (in all scripts) every reference
to stacks names and maybe this could be extended for controls too.
For example:

The developer writes this code on the stack script:

Code: Select all

on opencard
set the loc of stack "My New Stack" to the screenloc
end opencard
After closing the script editor, but before saving the stack, every reference to
a stack's labeled: "My New Stack" could be replaced with it's
IDE assigned non-modifiable name. For example:

Code: Select all

on opencard
set the loc of stack "b471de8f-4cc6-445f-909e-252e574fed5f" to the screenloc
end opencard
Could this actually work or be helpful to avoid breaking scripts or behaviors
after renaming a stack?

Al

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

Re: Add pref for renaming behiors

Post by bogs » Fri Aug 03, 2018 4:43 am

capellan wrote:
Thu Aug 02, 2018 9:26 pm
After closing the script editor, but before saving the stack, every reference to
a stack's labeled: "My New Stack" could be replaced with it's
IDE assigned non-modifiable name.
Curious how you see it working with stacks created previously Al? Do they get renamed if opened in a newer IDE with this feature set, just because I checked code in the Script Editor, then closed it? Something else?
Image

capellan
Posts: 607
Joined: Wed Aug 15, 2007 11:09 pm
Contact:

Re: Add pref for renaming behiors

Post by capellan » Fri Aug 03, 2018 5:00 am

This feature should be only for new stacks.

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

Re: Add pref for renaming behiors

Post by bogs » Fri Aug 03, 2018 6:52 am

So triggered by stack format version then? Sounds intriguing.
Image

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

Re: Add pref for renaming behiors

Post by dunbarx » Fri Aug 03, 2018 2:48 pm

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.

But stack ID's are now a moving target.

Perhaps creating a new immutable stack property might be the answer. It also might be useful in many other situations. I find comfort in such a stubborn entity.

Craig Newman
Last edited by dunbarx on Thu Aug 16, 2018 6:11 pm, edited 1 time in total.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6674
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Add pref for renaming behiors

Post by FourthWorld » Fri Aug 03, 2018 4:14 pm

IDs for all non-stack objects in xTalks are serial integers; in LiveCode these begin at 1001. IDs are generally unique, but only within a given stack.

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.

This is necessary since of course serial integers would not be unique when shared with others who may have stacks with the same ID. Indeed, even among one's own stacks, how could the engine know the IDs every stack ever made?

UUIDs are a modern solution to location-independent unique object identification. But in all fairness to LiveCode it's not a trivial problem, and MetaCard (the original name for what is now the LiveCode engine) predates the UUID spec (RFC 2144) by 12 years.

Using stack names as identifiers is easier in LiveCode than many other xTalks because every LiveCode object that has a visible name also has a label property. This allows us to use any visible label for the object that makes sense to the user, while keeping the object's name free for the developer to employ any convention which is both reasonably unique and has mnemonic value during coding.

From time to time, if we decide we don't like the original name we chose for a stack and want it to change it, this will require changes to any script or property that depends on that identifier.

But this is true of all objects, and during coding it's usually much more efficient to address objects by the mnemonic strings we chose for them rather than by ID.

For example, which of these is clearer to you?:

Code: Select all

get fld ID 2006
get fld "UserName"
IDs are well suited for ephemeral object references at runtime, such as putting the long ID of a control into a variable to then perform multiple actions on it. But writing IDs in code is rarely done, since memorizing integer IDs is far more difficult than using descriptive names we choose for them.

So from time to time we may decide to change names, and that will mean changing code and property assignments. LC's Replace tool should make short work of most such cases.

But changing names has work implications in any language. As Martin Fowler reminds us:

"There are only two hard things in Computer Science: cache invalidation and naming things."
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/

Jim Mac
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 28
Joined: Wed Jun 28, 2006 9:22 pm

Re: Add pref for renaming behiors

Post by Jim Mac » Fri Aug 03, 2018 6:55 pm

This got way deeper than I expected really quickly.... I know there are lots of potential work arounds/fixes (this is Livecode after all).

The key point for me is I now know that behaviors are not relative to the stack they inhabit which is counter to all I think about in terms of coding in LiveCode. That said, I rarely do anything outside of a main stack and a substack or two so I don't need a global solution. I'd be happy with a simple warning before I screw everything up.

My personal approach will likely be a preOpen script that saves the opening stack name, a closeStack script that runs through all the behaviors and adjusts all occurrences of the old name in behaviors to the new one if the name has changed and a new "workflow" that makes sure I don't forget to include them in any stack I do. (Or maybe that won't work?)

I can only do this because I now know what's going on. Imagine a new user opening a sample script then saving it with a new name so they don't screw up the original when they play and.... it's broken. Not a good newbie experience.

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

Re: Add pref for renaming behiors

Post by dunbarx » Fri Aug 03, 2018 10:30 pm

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.
Richard.

Do I have that wrong? I (always?) thought that HC stack ID's were permanent. You would think I would know that, and though I believe you, I will test when I get back to the office.

Craig

bwmilby
Posts: 263
Joined: Wed Jun 07, 2017 5:37 am
Location: Henrico, VA
Contact:

Re: Add pref for renaming behiors

Post by bwmilby » Fri Aug 03, 2018 11:08 pm

Jim Mac wrote:
Fri Aug 03, 2018 6:55 pm
Imagine a new user opening a sample script then saving it with a new name so they don't screw up the original when they play and.... it's broken. Not a good newbie experience.
I think LiveCode has this right. It does not use the long ID of the stack which would be the full path. It uses the actual stack name from the property inspector. So if you just do a ‘save as’ from within LC or copy and open from the OS, the behaviors will not break.
Brian Milby

Script Tracker https://github.com/bwmilby/scriptTracker

capellan
Posts: 607
Joined: Wed Aug 15, 2007 11:09 pm
Contact:

Re: Add pref for renaming behiors

Post by capellan » Sat Aug 04, 2018 2:47 am

I think that a new property like UUIDStackName could not break any scripts
and could become very useful for future developments.

By the way, I was checking HyperCard 2.1 and could not find the Stack ID property.
Only Cards, Backgrounds, Buttons, Fields, etc. have ID.

Al

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6674
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Add pref for renaming behiors

Post by FourthWorld » Sat Aug 04, 2018 4:44 am

capellan wrote:
Sat Aug 04, 2018 2:47 am
I think that a new property like UUIDStackName could not break any scripts
and could become very useful for future developments.
Possibly, but would require changes to the format of script-only stacks so they could become script-kinda-only-but-with-some-properties-but-not-others stacks. :)

Doable, but the team has seemed adamant about preferring to keep those script-only.

Changing object names has work implications, in any language. I don't believe it's practical for the IDE team to add a new feature and UI for every possible case where users may make choice they later don't like. Those expert enough to be using custom behaviors are likely able to quickly do a replace on that property.

With so many scripts in these forums for searching for all objects, it really shouldn't take but a few minutes for anyone in the community to make a plugin for this and drop it in RevOnline, leaving the engine team to focus on the many engine things in queue.
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/

Jim Mac
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 28
Joined: Wed Jun 28, 2006 9:22 pm

Re: Add pref for renaming behiors

Post by Jim Mac » Sat Aug 04, 2018 7:15 am

I agree. I don't want the team to be distracted from important things.
I also think running into this issue will be a valuable learning experience for others as it has been for me.
I posted simply because looking at the behavior name issue from a new user perspective seems like a real WTF moment.....

In hindsight, changing the name of a stack should be expected to break things inside the stack?
There's no real reason I should expect things to work as before..... except this is Livecode....

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?

Post Reply

Return to “Feature Requests”