I was thinking the same thing. I'm pretty sure that when an app for Windows uses DotNET Framework, it takes some time to initially load the framework, then the app can launch. Once the app is quit, I do not think it unloads DotNET Framework, because the next time I launch the app, the process is almost instantaneous.
If more than one app is using your "framework" (behavior script only stack) then it doesn't make sense to purge it. Now if you want to maintain a system of registering and unregistering your apps with your framework, and purging the framework when the last app quits, that would make sense. I find that a lot of times in lieu of an enhancement request, the problem can really be handled by a little ingenuity on the part of the end developer. As I have said in the past, Livecode is less like raw materials and a full set of tools (C variants or Java) and more like a constructor set. All the different parts have been made, and we really put the parts together to make something useful, like a toy house for example. The logical conclusion to any approach to less granularity than necessary would result in opening the box of the constructor set and finding inside walls and a roof. But what if I didn't want to make a house?? I guess I'm saying that it's more beneficial to keep as much flexibility in the hands of the developer as possible. It's up to us to detemine how best to put the parts together in a way that suits us. Bob S > On Feb 10, 2017, at 09:48 , Richard Gaskin via use-livecode > <email@example.com> wrote: > > > __ Delete behavior stacks from memory when stack using them are > > deleted [YES/NO] > > My vote: No. > > Different stack, different purge. > > I want to remain in control of when things get purged. _______________________________________________ use-livecode mailing list firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode