Monte, you request is a bit opaque to me..
-- to stay away from globals
-- to break up logical "areas of work/services" into separate scripts
-- to be able trace back to the original script I find myself doing a lot more
I find myself doing a lot of this;
behavior_Listen # parent of the stack "listen"
# which is serving as the controller/model for all things having to do with
on playlist_SetCurrent pList
put pList into sTargetPlayList
# so then in this script:
# behavior attached to the card in this stack
# which is responsible for all things UI/UX related. i.e the "view manager" if
I can at anytime do a kind of "reset" with
put playlist_GetCurrent() into tPlaylist
This architecture is all a bit new to me but turns out to be very functional
and pretty transparent…
so that "getter setter" thing… is that what you are looking for?
On 8/10/17, 3:50 PM, "use-livecode on behalf of Monte Goulding via
use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of
Basically anything where you follow a common pattern to do a thing but you
can’t abstract away so you don’t have to write the pattern any more.
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription