Best place to put code Card or stack script
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Best place to put code Card or stack script
I have a card with several number fields when I exit any of these fields I would like to make a recalculation of the card.
I would like to place the code for the recalculation either in the card script or the stack script so I only have
to do this once. My question is 2 part. Part 1 what do I put in the field script if I am using on closefield to tell livecode
to execute the recalculation in the card or stack script. Part 2 is it better to put this code in the card script or the stack script
I would like to place the code for the recalculation either in the card script or the stack script so I only have
to do this once. My question is 2 part. Part 1 what do I put in the field script if I am using on closefield to tell livecode
to execute the recalculation in the card or stack script. Part 2 is it better to put this code in the card script or the stack script
Re: Best place to put code Card or stack script
Hi.
You pretty much have this in hand. The important idea is to use the hierarchy to advantage.
If you are sure that your exitField and/or closeField handlers will only ever work the fields on that particular card, then I would use the card script. I like to keep things as local as possible, and perhaps one day, on another card, you may want different close/exitField handlers that do different things to the fields on that new card.
If you use the stack script (or even higher levels, like backScripts) the result will be identical at this juncture. But any other fields on other cards will also use those handlers, unless you trap them in their own card scripts. Ah. But then, that is the rationale for using the card script model in the first place.
This takes planning. That said, it is often impossible to plan. So start in the card script. You can always cut them into the stack if you need to.
Craig Newman
You pretty much have this in hand. The important idea is to use the hierarchy to advantage.
If you are sure that your exitField and/or closeField handlers will only ever work the fields on that particular card, then I would use the card script. I like to keep things as local as possible, and perhaps one day, on another card, you may want different close/exitField handlers that do different things to the fields on that new card.
If you use the stack script (or even higher levels, like backScripts) the result will be identical at this juncture. But any other fields on other cards will also use those handlers, unless you trap them in their own card scripts. Ah. But then, that is the rationale for using the card script model in the first place.
This takes planning. That said, it is often impossible to plan. So start in the card script. You can always cut them into the stack if you need to.
Craig Newman
Re: Best place to put code Card or stack script
Thanks I will put the handler in the card script. One simple question how does on close field in the
field script call on the handler in the card script to execute the recalculation?
field script call on the handler in the card script to execute the recalculation?
Re: Best place to put code Card or stack script
I think I answered my own question. I just needed to name the handler in the field script "rex" or some other name then
in the card script type
on rex
put fld aa + fld BB into fld cc
end rex
so simple I hope this is the best way
in the card script type
on rex
put fld aa + fld BB into fld cc
end rex
so simple I hope this is the best way
Re: Best place to put code Card or stack script
Yes, and you can use param for your handlerI think I answered my own question
Code: Select all
on rex pFld1,pFld2
put fld pFld1 + fld pFld2 into fld cc
end rex
https://alternatic.ch
Re: Best place to put code Card or stack script
Mike.
You have a "closeField" handler in both a certain field script and in the card script? And you do this because that particular field needs its own stuff done before the "general" card script handler works on it?
If so, then you could do it a couple of ways:
1- pass "closeField" at the end of the field script. That message will then go to the card.
2- test the target in the card script. If it returns the field of interest, do extra work in the card script handler.
Or do I have this wrong?
Craig
You have a "closeField" handler in both a certain field script and in the card script? And you do this because that particular field needs its own stuff done before the "general" card script handler works on it?
If so, then you could do it a couple of ways:
1- pass "closeField" at the end of the field script. That message will then go to the card.
2- test the target in the card script. If it returns the field of interest, do extra work in the card script handler.
Or do I have this wrong?
Craig
Re: Best place to put code Card or stack script
I placed the call to the handler rex at the end of the closefield handler in the field script it seems to
work well it manipulates the field first (rounds etc...) next it goes to the card script and runs the handler rex to
recalculate the card. The recalculation is where most of the work happens and having
it in one place in the card script is great. Thanks for your help
work well it manipulates the field first (rounds etc...) next it goes to the card script and runs the handler rex to
recalculate the card. The recalculation is where most of the work happens and having
it in one place in the card script is great. Thanks for your help

Re: Best place to put code Card or stack script
Leveraging the message path is one of the most awesome concepts going. I too prefer to keep handlers as local as they need to be, so that you don't have interference from other targets in the stack, but still have control over multiple targets with one script.
Behaviors (sic) are brilliant too.
But also on a more simple level, don't overlook that you can have specific handlers that can call other handlers and pass parameters to them. So it's very easy to have a "doStuff" handler somewhere in the card or stack and in the specific buttons you want, you can:
on mouseUp
doStuff
end mouseUp
But behaviors do that slicker.
Behaviors (sic) are brilliant too.
But also on a more simple level, don't overlook that you can have specific handlers that can call other handlers and pass parameters to them. So it's very easy to have a "doStuff" handler somewhere in the card or stack and in the specific buttons you want, you can:
on mouseUp
doStuff
end mouseUp
But behaviors do that slicker.