Re: How to set up a library?
Ben: > What is the best way to structure a library these days? Flashback to an interesting conversation, when LiveCode Ltd (or RunRev Ltd) asked me, "what is a library?" Not kidding; real question. It's like Newton Ltd asking you, "what is gravity?" That opened my eyes to how libraries have been underappreciated and underpromoted at times, even at the very top of the LC community. So I'm happy to see a thread about libraries. Thanks for starting it. Best way is most efficient way. What's most efficient depends on your current or desired workflow. > Currently I've got buttons with a script, and a 'mouseup' handler > to 'insert the script of me into back' in my object library. > But I don't think that's very modern. Neither way is extremely modern. But modern shouldn't be the overriding criterion for judging good design. Very true that good design is often modern, but conflating the two would be missing the point. Start using, insert script into - both introduced in 1.0, if the dictionary serves. There's nothing less modern about insert. Yet I've always preferred "start using." It suits my own style of organizing code (stacks or substacks) and loading it into memory. Not necessarily better; again depends on YOUR workflow and overall organization methods. And where you need the code in the message path. I've seen great button script inserts. (Although plenty of bad ones. Especially when inserting into front, it's a must to make sure the inserted code is pretty darn good.) And I've seen terrible code with start using! It's possible to really do it badly. But I'm biased in favor of start using for most work. > What's the right way to do it? Especially if I want to share it? So it's kind of a Ford/Chevy or AK/AR question. Used well, either will do. Either way, make sure initialization happens only once, don't tread on the user and seize control, try to anticipate how different users work in LiveCode and structure their scripts, etc. Don't duplicate code. And get a testing partner; he or she is a force multiplier. But if modern IS to be the overriding criterion - peer pressure/trends/fads - I'd say cool kids better use git, script-only stacks, AND also plenty of behaviors which were introduced much later than libraries themselves. All together. And don't forget to make it a MVP. Otherwise behind the times, not kewl fewl. :) Good topic. Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.com/ ___ 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
Re: How to set up a library?
On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. um - not 100% "no effect". If you have a 'librarystack' handler it will be run each time you 'start using' the stack, and therefore if it does something without checking for having been already run, you can get unexpected effects. (For example, if your librarystack handler was to explicitly set some variable to empty then that would overwrite (i.e. lose) any value set since the previous occurrence. Like others have said, I use a folder (I call it Libraries) with the 'My Livecode' folder to hold all my libraries (and I make sure they can be 'start using'ed multiple times. If I have a library which depends on other libraries, I give it a librarystack handler which (among other things) will 'start using' any libraries it requires. Alex. ___ 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
RE: How to set up a library?
I actually have a folder that I created called "myLibraries". You just need to put that folder into the path so that your application can see it. Sincerely, Clarence Martin Email: chi...@themartinz.com Phone: 626 6965561 -Original Message- From: use-livecode On Behalf Of Ben Rubinstein via use-livecode Sent: Thursday, December 31, 2020 10:19 AM To: use-livecode@lists.runrev.com Cc: Ben Rubinstein Subject: Re: How to set up a library? Thanks for responding Bob. Apologies for the confusion, I wasn't suggesting adding it in the actual application bundle; I was wondering whether there is a corresponding location in what used to be the "My LiveCode" folder in Documents. I.e. in that folder on my machine I see subfolders Extensions Externals Plugins Projects Resources Runtime and I wondered whether any of those had some blessed quality which would allow library stacks stored there to be loaded more easily than 'ordinary' stacks. Ben On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: > Trouble with putting a library in the Livecode libraries folder is every time > you upgrade Livecode, those may get deleted. This is especially true for OS > X, where those libraries are in the app bundle. I would not put a library in > that location. > > Also, you do not have to specify the path. Add the library to the Stack Files > of the stack, and then start using it by the stack short name. If you are > using a script only stack, you should also add the SOS to the stack files, > mainly because when you create a standalone these will get included in the > standalone. Otherwise I suppose you *could* start using a stack by full path > name or else it has to be in the current default folder. > > Setting the behavior of something is a one time thing. Start Using is > something that has to be done every time a stack is opened, unless another > stack in the IDE has done so. Doing it more than once has no effect, other > than pushing the script to the back of the stacks in use. > > The difference between the two is that a behavior is in the message path of > the object itself, and so it’s handlers are not accessible to any other > object unless you send or dispatch to that object. > > Start Using makes the script globally accessible to ALL stacks running in the > IDE (or in the Standalone). > > On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode > mailto:use-livecode@lists.runrev.com>> wrote: > > Thanks Alex and Bob for your responses. > > And if I make it a script-only stack, is there a clever place to store > it - e.g. the standard distribution libraries are in > .../Tools/Toolset/libraries/ > > Is there a convention or location which would allow me to reference the > library without having to specify the full path, for example? > > thanks, > > Ben > > ___ > 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
Re: How to set up a library?
Thanks for responding Bob. Apologies for the confusion, I wasn't suggesting adding it in the actual application bundle; I was wondering whether there is a corresponding location in what used to be the "My LiveCode" folder in Documents. I.e. in that folder on my machine I see subfolders Extensions Externals Plugins Projects Resources Runtime and I wondered whether any of those had some blessed quality which would allow library stacks stored there to be loaded more easily than 'ordinary' stacks. Ben On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: Trouble with putting a library in the Livecode libraries folder is every time you upgrade Livecode, those may get deleted. This is especially true for OS X, where those libraries are in the app bundle. I would not put a library in that location. Also, you do not have to specify the path. Add the library to the Stack Files of the stack, and then start using it by the stack short name. If you are using a script only stack, you should also add the SOS to the stack files, mainly because when you create a standalone these will get included in the standalone. Otherwise I suppose you *could* start using a stack by full path name or else it has to be in the current default folder. Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. The difference between the two is that a behavior is in the message path of the object itself, and so it’s handlers are not accessible to any other object unless you send or dispatch to that object. Start Using makes the script globally accessible to ALL stacks running in the IDE (or in the Standalone). On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben ___ 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
Re: How to set up a library?
BTW you may want to consider inserting anything with a mouseUp handler in the front, if you want every mouseUp to be trapped. If you only want the library’s mouseUp to be triggered “on demand” then insert into back and then pass mouseUp to trigger your library handler (assuming mouseUp is not trapped anywhere else in the message path.) For example, I have a mouseDown handler in a front script, where I then get the target and determine what kind of object it is, handling the objects I want (usually for contextual menus) and then passing at the end. Bob S On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. ___ 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
Re: How to set up a library?
Trouble with putting a library in the Livecode libraries folder is every time you upgrade Livecode, those may get deleted. This is especially true for OS X, where those libraries are in the app bundle. I would not put a library in that location. Also, you do not have to specify the path. Add the library to the Stack Files of the stack, and then start using it by the stack short name. If you are using a script only stack, you should also add the SOS to the stack files, mainly because when you create a standalone these will get included in the standalone. Otherwise I suppose you *could* start using a stack by full path name or else it has to be in the current default folder. Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. The difference between the two is that a behavior is in the message path of the object itself, and so it’s handlers are not accessible to any other object unless you send or dispatch to that object. Start Using makes the script globally accessible to ALL stacks running in the IDE (or in the Standalone). On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben ___ 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
Re: How to set up a library?
Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben On 29/12/2020 23:40, Alex Tweedly via use-livecode wrote: I'd make it a script-only stack, and then start using stack "..." (probably in an openstack handler - but could be anywhere you like for your own use). By far the easiest to share (and for others to accept when shared). Alex. P.S. And, should this library be useful in LCServer context, it means you can upload the stack to the server without getting annoying error messages about mixed line endings which Coda-2 and some others give on binary stacks). On 29/12/2020 19:34, Ben Rubinstein via use-livecode wrote: What is the best way to structure a library these days? Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. What's the right way to do it? Especially if I want to share it? TIA, Ben ___ 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
Re: How to set up a library?
I'd make it a script-only stack, and then start using stack "..." (probably in an openstack handler - but could be anywhere you like for your own use). By far the easiest to share (and for others to accept when shared). Alex. P.S. And, should this library be useful in LCServer context, it means you can upload the stack to the server without getting annoying error messages about mixed line endings which Coda-2 and some others give on binary stacks). On 29/12/2020 19:34, Ben Rubinstein via use-livecode wrote: What is the best way to structure a library these days? Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. What's the right way to do it? Especially if I want to share it? TIA, Ben ___ 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
Re: How to set up a library?
This is actually the only way. Besides Start Using a stack, which inserts the script of the target stack into back, if the script of a button is to be used as a library (or back/front script would be a better way to say it), insert into back or front is the way to do it. Otherwise setting the behavior of something will be persistent, but accomplishes the same thing really. It inserts the script of the object containing the behavior into the message path. Behaviors are a little different however when referring to me or this me. These return empty when in a front of back script and return the target and behavior of the target respectively when used in a behavior script. Bob S On Dec 29, 2020, at 11:34 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: What is the best way to structure a library these days? Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. What's the right way to do it? Especially if I want to share it? TIA, Ben ___ 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
