Monte, you request is a bit opaque to me..
but FWIW
-- 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
of this:
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
playlists etc.
on playlist_SetCurrent pList
put pList into sTargetPlayList
end playlist_SetCurrent
function playlist_GetCurrent
return sCurrentPlayListA["playListTitle"]
end playlist_GetCurrent
# so then in this script:
behavior_ListenSelectPlay
# behavior attached to the card in this stack
# which is responsible for all things UI/UX related. i.e the "view manager" if
you will
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
use-livecode@lists.runrev.com> wrote:
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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
