Behavior scripts not limited to buttons?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
-
- VIP Livecode Opensource Backer
- Posts: 9752
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Behavior scripts not limited to buttons?
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Behavior scripts not limited to buttons?
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Behavior scripts not limited to buttons?
...although in general I agree that it makes more sense to have fields inherit from fields, etc.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Behavior scripts not limited to buttons?
I'm not opposed, but what would be do for stacks that use behavior scripts? Substacks?mwieder wrote:...although in general I agree that it makes more sense to have fields inherit from fields, etc.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Behavior scripts not limited to buttons?
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
Change this to CT_LAYER in resolveparentscript... any non-card/stack object.
Change this in get prop to something like what I implemented for rugged id
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;
Code: Select all
t_control = t_stack -> getcontrolid(CT_BUTTON, t_script -> GetObjectId(), true);
Code: Select all
ep . setstringf("button id %d of stack \"%s\"", t_parent -> GetObjectId(), MCNameGetCString(t_parent -> GetObjectStack()));
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Behavior scripts not limited to buttons?
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 wrote: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...
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Behavior scripts not limited to buttons?
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: Behavior scripts not limited to buttons?
What was the reason behind behavior returning a rugged id?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Behavior scripts not limited to buttons?
Long ids specify an absolute path, which makes portability difficult, especially for something like the datagrid.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Behavior scripts not limited to buttons?
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...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: Behavior scripts not limited to buttons?
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:
rather than:
we should be able to:
Code: Select all
put the effective filename of the stack of objectRef
Code: Select all
put char 2 to -1 of word -1 of the long id of objectRef
Last edited by monte on Tue Jun 11, 2013 6:48 am, edited 1 time in total.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Behavior scripts not limited to buttons?
Yes. Absolutely yes.Do many people rely on the path in long id to get the filename of the mainstack?
If I need to store a preferences file next to an application I use the long id to find the file path.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Behavior scripts not limited to buttons?
OK... why don't you use the effective filename of this stack?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Behavior scripts not limited to buttons?
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Behavior scripts not limited to buttons?
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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/