Folks, What I am doing is using the stack script of substacks to hold code modules. This way, the search command works nicely. If I use external stacks for my "libraries" the search command doesn't seem to have an option to include them in a search without including the entire library, which seems to take forever. Also, the substack stack script handlers seem to be able to call handlers in other substack stack scripts without message path concerns. I figure that if I need to use the code in other projects later, I can easily make the substacks into library stacks. Keeping track of where specific scripts reside and using dispatch commands seems extremely cumbersome to me.
Another thing, which I didn't start doing until recently, but wish I had stared that way, is to put a prefix before each handler in a library. Like iml_myhandler, where iml_ goes in front of each handler name. That way it's much easier to remember where handlers are, as the project grows, Folks, I'm still new to livecode, so if I'm doing anything that will get me into trouble down the road, I'd like to hear about it. Like, the seeming lack of hierarchy in the message path of substack stack scripts. Is this likely to change? Cheers, Bill William Prothero http://es.earthednet.org > On May 8, 2014, at 6:37 AM, Dar Scott <d...@swcp.com> wrote: > > I think using a substack as a library is OK. > > Remember that the main stack is in the message path of the substack. So, you > will have the main stack twice in the message path for cards and controls. > This is probably fine. But, something like a keystroke counter in the main > stack might count them twice. > > There might be some packaging issues if you make a splash screen, but others > would know better than I. If the sub stack depends on the main stack and > they both become sub stacks in standalones, there is a potential for slightly > different behavior in the standalone. > > Dar > > > >> On May 8, 2014, at 7:11 AM, Terence Heaford <t.heaf...@btinternet.com> wrote: >> >> >> Thanks for your comments. >> >> I have just placed the DBRoutines into a substack and placed "start using" >> in the preOpenStack handler. >> >> That seems to be a workaround for not having folders in the IDE. >> >> Are there any downsides to this method? >> >> I have downloaded and tried GLX2 but there are issues on my Mac concerning >> the display of text being corrupted. >> >> Something like —> in GLX2 would be useful in the LiveCode IDE. >> >> I also thought that an updated IDE was one of the stretch goals of the >> Kickstarter campaign. >> How is that going? >> >> >> All the best >> >> Terry >> >> >>> On 8 May 2014, at 13:55, Dar Scott <d...@swcp.com> wrote: >>> >>> Stack libraries have some nice advantages for me. I sometimes put some >>> things such as tables into controls. They are often wrappers for >>> externals. (Or maybe the externals are helpers for the libraries.) >>> >>> If you have a card for putting odd things and the card never shows, you >>> might want to put some objects there to represent your modules and put the >>> scripts into those. Name them after the modules. put them in front or in >>> back as seems right when you open your stack. >>> >>> If you need some module only on cards with certain background groups, then >>> consider whether those scripts belong in the group. >>> >>> If you have a family of applications that use the same splash-screen main >>> stack, consider putting those things that are special to the family in that >>> stack. >>> >>> Dar Scott >>> Controls, Libraries and Externals >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 _______________________________________________ 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
