Behavior scripts not limited to buttons?

[dunbarx]

It is presumptuous of me to speak in this forum.

But is it contemplated that behavior scripts might be available in all objects, and not limited only to buttons? It is always possible to work around this, but there are times where the behavior script might be more naturally placed in a field, say, if the child objects to that script are also fields.

Just wondering...

Craig Newman

[FourthWorld]

It may one day become possible, but for not the object containing a behavior script can only be a button. Since it's used only as a generic script container, that it's a button will have no adverse effects on any scripts which use it as its behavior, such as fields, stacks, etc.

[mwieder]

...although in general I agree that it makes more sense to have fields inherit from fields, etc.

[FourthWorld]

...although in general I agree that it makes more sense to have fields inherit from fields, etc.

I'm not opposed, but what would be do for stacks that use behavior scripts? Substacks?

[monte]

This gets raised often... It's interesting that if behaviors were implemented as a faceless script container then it would never come up but because they make use of a button to hold the script that it comes up all the time... I just looked (very briefly) at the code and I think there's only a few small changes to support any control type. @runrevmark may want to chime in and tell me I didn't notice something huge but from what I can see then the following would fix it if we want it fixed:

Remove this from setparentscript

Code: Select all

// Check that the object is a button
	if (t_stat == ES_NORMAL && t_object -> gettype() != CT_BUTTON)
		t_stat = ES_ERROR;

Change this to CT_LAYER in resolveparentscript... any non-card/stack object.

Code: Select all

t_control = t_stack -> getcontrolid(CT_BUTTON, t_script -> GetObjectId(), true);

Change this in get prop to something like what I implemented for rugged id

Code: Select all

ep . setstringf("button id %d of stack \"%s\"", t_parent -> GetObjectId(), MCNameGetCString(t_parent -> GetObjectStack()));

[FourthWorld]

This gets raised often... It's interesting that if behaviors were implemented as a faceless script container then it would never come up but because they make use of a button to hold the script that it comes up all the time...

I think that's pretty much where they landed: as Kevin explained on the use-list some time ago, even a "faceless" container needs some on-screen representation so we can work with it, so the choice to use a button was simply a way to have a generic container without having to invent a new control type.

[monte]

Right but as far as I can tell it's just an object reference to a control and nothing about the control makes any difference other than the script... so it shouldn't be a big change if we want it...

[monte]

What was the reason behind behavior returning a rugged id?

[mwieder]

Long ids specify an absolute path, which makes portability difficult, especially for something like the datagrid.

[monte]

Right.. but what's retained under the hood is an id and a stack reference. That doesn't need to be what's returned by get prop. We could return a long id there just by using GetObject then getprop P_LONG_ID...

My point is if we aren't accepting rugged IDs into the language then why do we use them for behaviors?

BTW... looks like some stuff would need to move from MCButton to MCControl...

FWIW... I totally understand that the behavior is just a script container but I also think there's utility in allowing any object to be that container. For example, if you decide an object script should be a behavior rather than have it's own script (say you need multiple copies) at the moment you need to cut and paste the code to a button... If we allowed any control then it's one less step... one less cognitive leap... make this group behave like that one... etc...

[monte]

Hmm... more thoughts on this... perhaps we should either change long id to return the mainstack name rather than path because it's not like the path is actually helpful in resolving stack name conflicts or alternatively change the rugged concept to return the mainstack name rather than path... Do many people rely on the path in long id to get the filename of the mainstack? If so it highlights a flaw in the language that I see that we can't easily get metadata about an object... what's its card, what's its stack... what's its sharedGroup...

we should be able to:

Code: Select all

put the effective filename of the stack of objectRef

rather than:

Code: Select all

put char 2 to -1 of word -1 of the long id of objectRef

[mwieder]

Do many people rely on the path in long id to get the filename of the mainstack?

Yes. Absolutely yes.
If I need to store a preferences file next to an application I use the long id to find the file path.

[monte]

OK... why don't you use the effective filename of this stack?

[mwieder]

Because I didn't think of using it
It's sprinkled throughout my code, and I don't think I'm the only one.
I wouldn't mind replacing it with effective filename.

[monte]

Well luckily I wasn't being entirely serious when I suggested changing long ID... The point I was making is if we need something like rugged ID then why not have it... even if it's not the rugged ID I implemented... perhaps just a long id with a stack name instead of the path is all we need... If we don't need it then why do we use it for behaviors and why does the IDE have a revRuggedID function? I can definitely see why the datagrid row template property needs it... I can't think why behaviors need it... it's no more complicated to return long id for the behavior than the rugged ID form it's currently returning.