Modularising Code

Dar Scott dsc at swcp.com
Thu May 8 16:26:55 EDT 2014


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 <dsc at 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 <dsc at 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.heaford at 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 <dsc at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the Use-livecode mailing list