Arg. LiveCode doesn’t lie, but sleepy Dar might not point out what is significant.
Being twice in the message path is a characteristic of messages sent to libraries and has nothing to do with any being a substack. It is a library thing. The issue with the substack is that the main stack is in the path of messages sent to it. Enough said, before I say something stupid again. Dar On May 8, 2014, at 2:04 PM, Dar Scott <d...@swcp.com> wrote: > I goofed. What I said isn’t right. I didn’t remember the quirk right. > > Here it is right from LiveCode itself for a stack, its substack also wearing > the hat of a library, and some other stack. > > Listed is the target and the current stack name in the message path crawl. > (Non-stacks are skipped in the message path log.) > > button "Test" -- stack "Test main stack" > button "Test" -- stack "Test Sub Stack" of stack "Test main stack" > bottom > > stack "Test Alt Stack" -- stack "Test Alt Stack" > stack "Test Alt Stack" -- stack "Test Sub Stack" of stack "Test main stack" > bottom > > stack "Test Sub Stack" -- stack "Test Sub Stack" of stack "Test main stack" > stack "Test Sub Stack" -- stack "Test main stack" > stack "Test Sub Stack" -- stack "Test Sub Stack" of stack "Test main stack" > bottom > > The first two cases are as we would expect for any library stack. > > The third case would apply to things such as messages sent to the substack. > I don’t know about built-in messages like socketTimeout. As you can see the > substack is in the message path twice. Handlers that change something and > pass would be affected. > > Dar > > > On May 8, 2014, at 7: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 _______________________________________________ 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
