Modularising Code

Earthednet-wp prothero at earthednet.org
Thu May 8 10:26:46 EDT 2014


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 <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




More information about the Use-livecode mailing list