Re: Documentation [was: Re: v8 DP3]
On 2015-08-28 10:28, Richmond wrote: https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-https-recommended When you view a repository while signed in to your account First of all, where do I find the GIT interface on my computer so that I can log into it, or, for the sake of argument, how can I log into the GitHub using Atom (which I installed just before breakfast), clone stuff and get to work? Technically, you don't actually need to install anything on your computer to make changes to the documentation. You can actually do it all through the GitHub website! Ali posted some instructions here: http://quality.runrev.com/show_bug.cgi?id=15347#c5 Peter -- Dr Peter Brett peter.br...@livecode.com LiveCode Open Source Team LiveCode on reddit! https://reddit.com/r/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: Script Editor future (was Open Source Kickstarter Report Card)
On 2015-08-29 04:43, Kay C Lan wrote: Oh, and just a slight tangent. I've seen it mentioned before but it hadn't really registered until I was playing with LC8 yesterday, but the new 'Script only Stack' would seem to be the perfect beast to offer up as a guinea pig for Text Editor integration. If my assumptions* are correct (unlikely) then there will be only a single block of text involved which would greatly simplify the tracking and sync process. Get TE Integration to work on Script only Stacks first, and once sorted, move on to any stack. *I'm assuming there are no objects, so you can't have button, field, front or back scripts. No card script? Is there ONLY one stack script? Your assumptions are correct. No card script, only a single stack script, all as a block of text. Here's an example from the LiveCode 8 script editor: https://github.com/runrev/livecode-ide/blob/develop/Toolset/palettes/script%20editor/behaviors/revsestackbehavior.livecodescript Peter -- Dr Peter Brett peter.br...@livecode.com LiveCode Open Source Team LiveCode on reddit! https://reddit.com/r/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: Documentation [was: Re: v8 DP3]
On 08/29/2015 10:04 AM, Peter TB Brett wrote: On 2015-08-28 10:28, Richmond wrote: https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-https-recommended When you view a repository while signed in to your account First of all, where do I find the GIT interface on my computer so that I can log into it, or, for the sake of argument, how can I log into the GitHub using Atom (which I installed just before breakfast), clone stuff and get to work? Technically, you don't actually need to install anything on your computer to make changes to the documentation. You can actually do it all through the GitHub website! Ali posted some instructions here: http://quality.runrev.com/show_bug.cgi?id=15347#c5 Peter That does look a whole lot simpler. Thank you very much. Richmond. ___ 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: Script Editor future (was Open Source Kickstarter Report Card)
That URL is not working. Probably should be: http://forums.livecode.com/viewtopic.php?f=66t=25065p=130099hilit=scriptOnly#p130099 Peter On Aug 29, 2015, at 12:53 AM, Monte Goulding mo...@sweattechnologies.com wrote: scriptOnly ___ 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
A book for babies?
If you are*NOT* interested in teaching *small children* /LiveCode/ stop reading now. --- Having taught a reasonably successful, relatively intensive course to *Primary level** **children* during the summer, and starting a once-a-week thing in October I am quite seriously thinking of putting together a *book* for Primary kids. This would *NOT* be full of theorising, and *NOT* like a 'standard' text book; rather a hands-on cookery book. Obviously, a significant part of this book will be pictorial. HOWEVER . . . Seeing the vast and significant changes coming with *LiveCode 8.0.0.* [and, to be honest, all I taught the children was doable in LC 4.5] including its interface changes (at the moment I'm thinking of the *preferences** **palette* and the *toolBar* stack) . . . I am really wondering what the point is, as, any book I start on now will either feature screen shots of the *LC 7 interface* or the *LC 8 alpha interface*; both of which may go down the pan just as my book is ready. ALSO . . . my course that will run from October to May will us LC 7 (especially as the LC 8 series is in a state of flux) . . . so any extra stuff arising (and, with hindsight, I can see lots of gaps that need to be plugged) will also be framed in terms of the LC 7 interface. As soon as a FIXED interface for LC 8 (???) is released I will have to sit down and make myself comfortable with it even before I start dishing it out either to kids in class or in the form of a book. -- I should be glad of any advice, comments, and so on about my quandary. -- In the light of some favourable responses I am wondering about releasing beta versions of my chapters under a non-disclosure agreement to interested parties to torture their children with on the understanding that they will 'pay' for them by giving me vigorous feedback. -- In light of the discussions anent a possible 'unified IDE' ['that' picture], I also would like to know what chances there are of that sort of thing being on the cards, whether it would be locked-in [heaven forfend] or optional, and so on, as, were it to be present in LC 8.x.x it might be necessary to write a book with what could be termed a double feature [think Rocky Horror Show] where almost every single screen shot has to be reduplicated for the two interfaces . . . --- I have no great desire to put together the sort of book I am talking about to find that it is outdated as soon as it comes off the presses. Richmond. ___ 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: Script Editor future (was Open Source Kickstarter Report Card)
Hi Peter Has anyone seen my post on the engine forum about a scriptOnly property for stacks: http://forums.livecode.com/viewtopic.php?f=66t=25065 Happy to contribute it Cheers Monte Sent from my iPhone On 29 Aug 2015, at 5:00 pm, Peter TB Brett peter.br...@livecode.com wrote: Your assumptions are correct. No card script, only a single stack script, all as a block of text. ___ 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
[Bug] Red Dot Breakpoints Ignored - Recipe
In line with a recent post I made mention of the fact that I don't use Red Dot breakpoints as they are ignored too often. I know others have had similar complaints. But in the interest of seeing if improvements have been made I just had a go in LC 7.1 rc 1 on OS X 10.9.5 and made the following discovery. New Mainstack with Script Debug Mode On. Add a button Add this script to the mouseUp handler of the button. repeat with x = 1 to 10 add 1 to x end repeat beep Apply and click the button and confirm it beeps. Now add a Red Dot breakpoint at the line: add 1 to x Add the following Breakpoint condition: x 4 Click the button and confirm the Debugger stops with x shown as 5 Now amend the condition to: x = 4 Click the button and on my machine the Red Dot is ignored. Now amend the condition to: the quick brown fox Click the button and on my machine the Red Dot is ignored. From what I can tell there is no validation of what you type into the conditional box and if it happens to be invalid, then the Red Dot is ignored. Very easy if you happen to have a long and complex condition and just happen to be missing a ) or a . The fact that valid = conditions are also ignored is clearly a bug. I expected to find a Bug Report at the QCC but nothing stuck out. I know that this has been a long standing issue so can: a) you confirm that you see this too b) suggest an appropriate bug number to add my findings. ___ 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: Script Editor future (was Open Source Kickstarter Report Card)
On 2015-08-29 08:53, Monte Goulding wrote: Hi Peter Has anyone seen my post on the engine forum about a scriptOnly property for stacks: http://forums.livecode.com/viewtopic.php?f=66t=25065 Happy to contribute it This looks like the sort of thing that's best off being looked at by Mark Waddingham. Unfortunately my last day before my annual holiday is the day before he gets back from his annual holiday, so I'm not going to be able to bring this up with him for at least a couple of weeks. Can I suggest that you e-mail him directly? Or just submit a PR on GitHub, that'll make sure it doesn't get forgotten about. ;-) Peter -- Dr Peter Brett peter.br...@livecode.com LiveCode Open Source Team LiveCode on reddit! https://reddit.com/r/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: A book for babies?
Richmond, Your concerns are very valid, with LC still in the midst of lots of changes. Here are some immediate rambling thoughts, perhaps obvious, but for what they're worth I like the workbook format. Very appropriate. Ideally, it might be distributed as an ebook or app type book that can be easily updated. If the students need print (I would think they would), it's more difficult. But perhaps the book could be printed, workbook style, by the purchaser at a local print store (like Kinko's in the US). I don't know how this could be set up so you get income from it, though. Hmmm, I wonder if any of these on demand type print stores could do one-offs for individuals, from a server master. I haven't investigated this, but I think Kinko's does this in the US. Not sure if they can return royalties to the author. Sounds like an obvious service, tho so it might be worth investigating. I think it is a great idea to get a few folks to test it with their kids, and give feedback. It is bound to improve the book. Regarding being a tester, my contact with my 10yr old grandson varies depending on factors out of my control. If it looks like I would have regular contact, I'd love to try it out on him. No guarantee he would get into it, tho. My son is a 3'rd grade teacher and I might be able to interest him, but he is into (with his students) Lego Robotics, Scratch and Arduino (a bit). Best, Bill William Prothero http://es.earthednet.org On Aug 29, 2015, at 12:20 AM, Richmond richmondmathew...@gmail.com wrote: If you are*NOT* interested in teaching *small children* /LiveCode/ stop reading now. --- Having taught a reasonably successful, relatively intensive course to *Primary level** **children* during the summer, and starting a once-a-week thing in October I am quite seriously thinking of putting together a *book* for Primary kids. This would *NOT* be full of theorising, and *NOT* like a 'standard' text book; rather a hands-on cookery book. Obviously, a significant part of this book will be pictorial. HOWEVER . . . Seeing the vast and significant changes coming with *LiveCode 8.0.0.* [and, to be honest, all I taught the children was doable in LC 4.5] including its interface changes (at the moment I'm thinking of the *preferences** **palette* and the *toolBar* stack) . . . I am really wondering what the point is, as, any book I start on now will either feature screen shots of the *LC 7 interface* or the *LC 8 alpha interface*; both of which may go down the pan just as my book is ready. ALSO . . . my course that will run from October to May will us LC 7 (especially as the LC 8 series is in a state of flux) . . . so any extra stuff arising (and, with hindsight, I can see lots of gaps that need to be plugged) will also be framed in terms of the LC 7 interface. As soon as a FIXED interface for LC 8 (???) is released I will have to sit down and make myself comfortable with it even before I start dishing it out either to kids in class or in the form of a book. -- I should be glad of any advice, comments, and so on about my quandary. -- In the light of some favourable responses I am wondering about releasing beta versions of my chapters under a non-disclosure agreement to interested parties to torture their children with on the understanding that they will 'pay' for them by giving me vigorous feedback. -- In light of the discussions anent a possible 'unified IDE' ['that' picture], I also would like to know what chances there are of that sort of thing being on the cards, whether it would be locked-in [heaven forfend] or optional, and so on, as, were it to be present in LC 8.x.x it might be necessary to write a book with what could be termed a double feature [think Rocky Horror Show] where almost every single screen shot has to be reduplicated for the two interfaces . . . --- I have no great desire to put together the sort of book I am talking about to find that it is outdated as soon as it comes off the presses. Richmond. ___ 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: [Bug] Red Dot Breakpoints Ignored - Recipe
Kay C Lan wrote: In line with a recent post I made mention of the fact that I don't use Red Dot breakpoints as they are ignored too often. I know others have had similar complaints. But in the interest of seeing if improvements have been made I just had a go in LC 7.1 rc 1 on OS X 10.9.5 and made the following discovery. New Mainstack with Script Debug Mode On. Add a button Add this script to the mouseUp handler of the button. repeat with x = 1 to 10 add 1 to x end repeat beep Apply and click the button and confirm it beeps. Now add a Red Dot breakpoint at the line: add 1 to x Add the following Breakpoint condition: x 4 Click the button and confirm the Debugger stops with x shown as 5 Now amend the condition to: x = 4 Click the button and on my machine the Red Dot is ignored. Now amend the condition to: the quick brown fox Click the button and on my machine the Red Dot is ignored. The bad news is that I was able to confirm that the x=4 condition is ignored in the LC debugger. The good news is that the breakpoint triggers as expected when using an experimental debugger I'd written years ago. That debugger is very sparse by design, with very minimal features and relying heavily on native engine behavior. So it would seem the engine is fine, and all that's needed is some fix to the scripts in the IDE debugger. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Script Editor future (was Open Source Kickstarter Report Card)
I'm still in the early days of using the sts plugin but I believe the restriction on not having the script editor window open at the same time is to avoid clashes if edits are made to the same script in both places. On Sat, Aug 29, 2015 at 9:15 AM Richard Gaskin ambassa...@fourthworld.com wrote: Kay C Lan wrote: On Fri, Aug 28, 2015 at 10:46 PM, Richard Gaskin wrote: Kay C Lan wrote: a better mechanism to track the changes and transfer those back and forth - that improvement can only be done from the mothership. What's needed? Let's make it so. Love the positive attitude :-) Just being selfish: I spend a lot of time in LC, so anything that helps make the workflow smoother benefits me. From memory stsMLXEditor was written when the SE was a seperate animal to the Debugger, hence: The external editor will not open a script if the IDE script editor window is open. Should be fixable, likely something that can be changed in stsMLXEditor. I think when the SE and Debugger merged stsMLXEditor became less useful because it was no longer possible to have just the Debugger open and my TE. MetaCard when through a similar transition, and while some prefer it I don't. If nothing else, having one window designed to perform to different and distinctly complex tasks complicates the code, a lot. But also, once a debugger is made separate from an editor it can be used in contexts where editing may not be possible, such as debugging standalones. I haven't had a look for quite a while, so maybe I need to give it another whirl and see - although it looks as though a few others are giving it a go so maybe they'll come up with some constructive criticisms. Please do. Your insights are often very valuable, and in this case the benefits nay extend beyond editor integration since at the heart of this is a question about inter-app communication, which has even broader applications. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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 ___ 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: [Bug] Red Dot Breakpoints Ignored - Recipe
On 08/29/2015 03:53 AM, Kay C Lan wrote: repeat with x = 1 to 10 add 1 to x end repeat beep It's really not a good idea to try to mess with the loop index while it's running. Do this instead: put 1 into y repeat with x = 1 to 10 add 1 to y end repeat beep and set the break condition on the 'add 1 to y' line -- Mark Wieder ahsoftw...@gmail.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: Script Editor future (was Open Source Kickstarter Report Card)
Kay C Lan wrote: On Fri, Aug 28, 2015 at 10:46 PM, Richard Gaskin wrote: Kay C Lan wrote: a better mechanism to track the changes and transfer those back and forth - that improvement can only be done from the mothership. What's needed? Let's make it so. Love the positive attitude :-) Just being selfish: I spend a lot of time in LC, so anything that helps make the workflow smoother benefits me. From memory stsMLXEditor was written when the SE was a seperate animal to the Debugger, hence: The external editor will not open a script if the IDE script editor window is open. Should be fixable, likely something that can be changed in stsMLXEditor. I think when the SE and Debugger merged stsMLXEditor became less useful because it was no longer possible to have just the Debugger open and my TE. MetaCard when through a similar transition, and while some prefer it I don't. If nothing else, having one window designed to perform to different and distinctly complex tasks complicates the code, a lot. But also, once a debugger is made separate from an editor it can be used in contexts where editing may not be possible, such as debugging standalones. I haven't had a look for quite a while, so maybe I need to give it another whirl and see - although it looks as though a few others are giving it a go so maybe they'll come up with some constructive criticisms. Please do. Your insights are often very valuable, and in this case the benefits nay extend beyond editor integration since at the heart of this is a question about inter-app communication, which has even broader applications. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Font Number Conversion?
Hi All: I'm struggling to to do some converting of Unicode icon font characters and am lost in number formats and representations. For example, a character can be represented in these forms: Decimal: 58880 Unicode: E600 HTML: #58880; CSS: \f230 Does anyone know how the CSS number is derived? I've tried all manner of baseConvert, codepointToNum, etc, and the only result I've been able to achieve is a headache. I'm sure this is pretty straightforward but I'm not a numbers guy. Thanks in advance for any numerical enlightenment. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design ___ 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: [Bug] Red Dot Breakpoints Ignored - Recipe
Mark Wieder wrote: On 08/29/2015 03:53 AM, Kay C Lan wrote: repeat with x = 1 to 10 add 1 to x end repeat beep It's really not a good idea to try to mess with the loop index while it's running. Do this instead: put 1 into y repeat with x = 1 to 10 add 1 to y end repeat beep Good catch, Mark. We can trace out the logic of the original with: on mouseUp repeat with x = 1 to 10 put x cr after msg add 1 to x end repeat beep end mouseUp ...and get: 1 3 5 7 9 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Font Number Conversion?
On 08/29/2015 09:43 PM, Scott Rossi wrote: Hi All: I'm struggling to to do some converting of Unicode icon font characters and am lost in number formats and representations. For example, a character can be represented in these forms: Decimal: 58880 Unicode: E600 HTML: #58880; CSS: \f230 Does anyone know how the CSS number is derived? I've tried all manner of baseConvert, codepointToNum, etc, and the only result I've been able to achieve is a headache. I'm sure this is pretty straightforward but I'm not a numbers guy. Thanks in advance for any numerical enlightenment. Regards, I don't understand CSS either; but I found this for those of us who cannot be bothered: https://www.evotech.net/articles/testjsentities.html Richmond. ___ 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: Font Number Conversion?
On 08/29/2015 10:23 PM, Richmond wrote: On 08/29/2015 09:43 PM, Scott Rossi wrote: Hi All: I'm struggling to to do some converting of Unicode icon font characters and am lost in number formats and representations. For example, a character can be represented in these forms: Decimal: 58880 Unicode: E600 HTML: #58880; CSS: \f230 Does anyone know how the CSS number is derived? I've tried all manner of baseConvert, codepointToNum, etc, and the only result I've been able to achieve is a headache. I'm sure this is pretty straightforward but I'm not a numbers guy. Thanks in advance for any numerical enlightenment. Regards, I don't understand CSS either; but I found this for those of us who cannot be bothered: https://www.evotech.net/articles/testjsentities.html Richmond. https://www.unicod.es/ ___ 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: Script Editor future (was Open Source Kickstarter Report Card)
On 29 Aug 2015, at 10:22 pm, Peter TB Brett peter.br...@livecode.com wrote: This looks like the sort of thing that's best off being looked at by Mark Waddingham. Unfortunately my last day before my annual holiday is the day before he gets back from his annual holiday, so I'm not going to be able to bring this up with him for at least a couple of weeks. Can I suggest that you e-mail him directly? I’ll just wait for Mark to get back. It’s a simple one but there’s obviously dire consequences for your stack objects if you set the scriptOnly to true so I’d like to get the nod before bothering. The engine forum has gone fairly quiet lately but the original idea was we would propose stuff we wanted to do then get the nod on syntax and whether it would be accepted if we did it etc. It may be that script only stacks are short term and the long term plan is not to have these scripts be stacks but update start using, back|front script and behavior to point to files rater than objects. Is that why they aren’t documented? Or just submit a PR on GitHub, that'll make sure it doesn't get forgotten about. ;-) I actually had some PRs that were forgotten about although I think both of them have now or will in the future at least become irrelevant because of widgets. ___ 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: Script-only stacks [was: Re: Script Editor future]
On 2015-08-29 23:05, Monte Goulding wrote: On 29 Aug 2015, at 10:22 pm, Peter TB Brett peter.br...@livecode.com wrote: This looks like the sort of thing that's best off being looked at by Mark Waddingham. Unfortunately my last day before my annual holiday is the day before he gets back from his annual holiday, so I'm not going to be able to bring this up with him for at least a couple of weeks. Can I suggest that you e-mail him directly? I’ll just wait for Mark to get back. It’s a simple one but there’s obviously dire consequences for your stack objects if you set the scriptOnly to true so I’d like to get the nod before bothering. The engine forum has gone fairly quiet lately but the original idea was we would propose stuff we wanted to do then get the nod on syntax and whether it would be accepted if we did it etc. It may be that script only stacks are short term and the long term plan is not to have these scripts be stacks but update start using, back|front script and behavior to point to files rater than objects. Is that why they aren’t documented? I *think* Mark will be back in the office on Monday, so he'll probably see this exchange At the moment I usually treat normal stacks and script-only stacks as totally different things. I think of normal stacks as places for UI and trivial glue code, and script-only stacks as places for complex handler libraries and behaviours. They have different filenames too (.livecode vs .livecodescript). My instinct is that adding a way to switch a stack back and forth between normal and script-only isn't very intuitive, and could cause dire consequences as you suggest. On the other hand, having a *read only* scriptOnly property (or some equivalent) sounds like it could be pretty useful. We *really* need documentation with more structure. I can't remember how one tests what sort of object something is, and the dictionary isn't giving me any hints... Or just submit a PR on GitHub, that'll make sure it doesn't get forgotten about. ;-) I actually had some PRs that were forgotten about although I think both of them have now or will in the future at least become irrelevant because of widgets. Oops, sorry. I shouldn't let these things slip through the cracks. It's a lot easier now that there's a defined process for accepting contributions! The processes for community contributors and LiveCode employees are now pretty much the same -- the only two differences are that 1) we still can't accept binary stack changes directly (sorry :-/) and 2) employees don't have to sign the CLA. If you've got some PRs that have been overlooked about but which are still relevant, let me know and I'll try and make sure they get looked at... Peter -- Dr Peter Brett peter.br...@livecode.com LiveCode Open Source Team LiveCode on reddit! https://reddit.com/r/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: [Bug] Red Dot Breakpoints Ignored - Recipe
On 08/29/2015 03:53 AM, Kay C Lan wrote: I expected to find a Bug Report at the QCC but nothing stuck out. I know that this has been a long standing issue so can: a) you confirm that you see this too b) suggest an appropriate bug number to add my findings. That said, the way LiveCode deals with breakpoint conditions is pretty screwy. If you apply a condition to a breakpoint, it it stored in a custom property of the stack. When a breakpoint occurs, the conditions are checked. But they're global to the stack. Try this: on mouseUp put 1 into x repeat with y = 1 to 10 add 1 to x end repeat end mouseUp on grunt put 1 into x repeat with y = 1 to 10 add 1 to x end repeat end grunt Now set breakpoints on both add lines, and add a condition to only the second line: x 3 Click the button and the breakpoint fires only when the condition is met, even though you set it for a different line. It's not so much a bug as a systemic failure, because in order to change the behavior the script editor and debugger would have to change what they do in some seriously wide-sweeping ways. The oddest part to me is that there's already a mechanism in the engine for dealing with this, but the IDE doesn't use it. -- Mark Wieder ahsoftw...@gmail.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: [Bug] Red Dot Breakpoints Ignored - Recipe
Mark Wieder wrote: The oddest part to me is that there's already a mechanism in the engine for dealing with this, but the IDE doesn't use it. What is that mechanism? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Script-only stacks [was: Re: Script Editor future]
I agree that any scriptOnly property should be read-only, thus eliminating any potential dire consequences. After all, you can easily lossily scriptify a stack by creating a new script-only and setting the script to another one. Whilst I agree that the main use of script only stacks should be for behaviors and libraries, in the IDE we are using script-only stacks as UI as well - after all it is only a small additional step if you are using resize handlers to also have the stack create the UI elements when it opens. On Sat, Aug 29, 2015 at 11:24 PM Peter TB Brett peter.br...@livecode.com wrote: On 2015-08-29 23:05, Monte Goulding wrote: On 29 Aug 2015, at 10:22 pm, Peter TB Brett peter.br...@livecode.com wrote: This looks like the sort of thing that's best off being looked at by Mark Waddingham. Unfortunately my last day before my annual holiday is the day before he gets back from his annual holiday, so I'm not going to be able to bring this up with him for at least a couple of weeks. Can I suggest that you e-mail him directly? I’ll just wait for Mark to get back. It’s a simple one but there’s obviously dire consequences for your stack objects if you set the scriptOnly to true so I’d like to get the nod before bothering. The engine forum has gone fairly quiet lately but the original idea was we would propose stuff we wanted to do then get the nod on syntax and whether it would be accepted if we did it etc. It may be that script only stacks are short term and the long term plan is not to have these scripts be stacks but update start using, back|front script and behavior to point to files rater than objects. Is that why they aren’t documented? I *think* Mark will be back in the office on Monday, so he'll probably see this exchange At the moment I usually treat normal stacks and script-only stacks as totally different things. I think of normal stacks as places for UI and trivial glue code, and script-only stacks as places for complex handler libraries and behaviours. They have different filenames too (.livecode vs .livecodescript). My instinct is that adding a way to switch a stack back and forth between normal and script-only isn't very intuitive, and could cause dire consequences as you suggest. On the other hand, having a *read only* scriptOnly property (or some equivalent) sounds like it could be pretty useful. We *really* need documentation with more structure. I can't remember how one tests what sort of object something is, and the dictionary isn't giving me any hints... Or just submit a PR on GitHub, that'll make sure it doesn't get forgotten about. ;-) I actually had some PRs that were forgotten about although I think both of them have now or will in the future at least become irrelevant because of widgets. Oops, sorry. I shouldn't let these things slip through the cracks. It's a lot easier now that there's a defined process for accepting contributions! The processes for community contributors and LiveCode employees are now pretty much the same -- the only two differences are that 1) we still can't accept binary stack changes directly (sorry :-/) and 2) employees don't have to sign the CLA. If you've got some PRs that have been overlooked about but which are still relevant, let me know and I'll try and make sure they get looked at... Peter -- Dr Peter Brett peter.br...@livecode.com LiveCode Open Source Team LiveCode on reddit! https://reddit.com/r/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
More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
7.1.rc 1 I could have sworn this used to work: make stack # Call it no. 1 utilities create button set traversalON of the button to false on mouseUp set the defaultstack to the topStack put selectedChunk() end mouseUp set stack 1 to palette mode. go to stack 2 with text in a field selected in the utilities stack... click the button: even though the traversal is set to false for the button the text selection in the top stack field is lost /de-selected result char 1 to 0 of fld 1 ?? BR ___ 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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
Brahmanathaswami wrote: 7.1.rc 1 I could have sworn this used to work: make stack # Call it no. 1 utilities create button set traversalON of the button to false on mouseUp set the defaultstack to the topStack put selectedChunk() end mouseUp set stack 1 to palette mode. go to stack 2 with text in a field selected in the utilities stack... click the button: even though the traversal is set to false for the button the text selection in the top stack field is lost /de-selected result char 1 to 0 of fld 1 ?? Works here, and given how much of the IDE relies on that sort of thing I'd be surprised it a regression survived release. Have you double-checked the palette mode, and the button's traversalOn? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Setting DefaultStack to TopStack does not make it's stack script available?
7.1 rc(1) I am trying to create some tools that can be used across many stacks. in some cases it's not completely generic and I want to have functions unique to scripts in the topstack to fire e.g. stack 1 : utilities.livecode # set to palette mode stack 2: topstack: myProject.livecode in Stack 1 we have this button: on mouseUp set the defaultstack to the topstack put the htmltext of fld textcontent into url ( file:// localPath() data/about-this-app.html) end mouseUp But I'm getting an error because Stack 1 (in palette mode) cannot find the function localPath() Is this a bug... I could have sworn before that if you set the defaultStack to the topstack then all it's scripts became part off of the message path. But not today... BR ___ 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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
Seems like this has been the way it is in osx as long as I can remember, but it does seem like the no traversal/palette tool stack would solve it. Works fine in windows. On Sat, Aug 29, 2015 at 2:23 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Brahmanathaswami wrote: 7.1.rc 1 I could have sworn this used to work: make stack # Call it no. 1 utilities create button set traversalON of the button to false on mouseUp set the defaultstack to the topStack put selectedChunk() end mouseUp set stack 1 to palette mode. go to stack 2 with text in a field selected in the utilities stack... click the button: even though the traversal is set to false for the button the text selection in the top stack field is lost /de-selected result char 1 to 0 of fld 1 ?? Works here, and given how much of the IDE relies on that sort of thing I'd be surprised it a regression survived release. Have you double-checked the palette mode, and the button's traversalOn? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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 ___ 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: [Bug] Red Dot Breakpoints Ignored - Recipe
On Sun, Aug 30, 2015 at 1:56 AM, Mark Wieder mwie...@ahsoftware.net wrote: It's really not a good idea to try to mess with the loop index while it's running. Do this instead: put 1 into y repeat with x = 1 to 10 add 1 to y end repeat beep and set the break condition on the 'add 1 to y' line Yes, good catch, except if I do add the breakpoint at 'add 1 to y' and create the condition: (x = 4 or (x = 7) The debugger does not stop because the condtion isn't invalid but it doesn't tell me that - well it didn't use to but now I know that a reason that Red Dots are ignored is because of a mistake in my conditional statement it will trigger me to load it into the msg box and see if it works. What is the bug number for Red Dots ignored, I'd like to add my thoughts that after clicking the Ok button on the conditional statement that a validity check MUST be carried out. Surely this must be one of the reasons for user frustration with Red Dots. ___ 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: Font Number Conversion?
Answering my own question: Turns out there were two versions of the font I was looking at, with characters ordered differently internally. [sigh] Nice waste of time and loss of hair on this one. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 8/29/15, 11:43 AM, Scott Rossi sc...@tactilemedia.com wrote: Hi All: I'm struggling to to do some converting of Unicode icon font characters and am lost in number formats and representations. For example, a character can be represented in these forms: Decimal: 58880 Unicode: E600 HTML: #58880; CSS: \f230 Does anyone know how the CSS number is derived? I've tried all manner of baseConvert, codepointToNum, etc, and the only result I've been able to achieve is a headache. I'm sure this is pretty straightforward but I'm not a numbers guy. Thanks in advance for any numerical enlightenment. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design ___ 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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
Agreed... ideally it would be some how documented... otherwise the presumption is if autotab is not checked for a field there is no reason for the engine to insist that the cursor go there if the traversal is true. but, yes... there are bigger fish to fry. -- Swasti Astu, Be Well! Brahmanathaswami Kauai's Hindu Monastery www.HimalayanAcademy.com Richard Gaskin wrote: Personally I think there are bigger fish to fry (man, it would so cool if I could just copy and paste text on Linux, or have an option control with a label that could be read, or a text baseline on ostensibly standard buttons that's actually in a standard position), but maybe this is important to some... ___ 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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
Brahmanathaswami wrote: Agreed... ideally it would be some how documented... Ah, but that's the hard part: where? For all I know it may even be documented already, but I can't imagine where I might go to learn about it. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: [Bug] Red Dot Breakpoints Ignored - Recipe
On Sun, Aug 30, 2015 at 11:47 AM, Kay C Lan lan.kc.macm...@gmail.com wrote: because the condtion isn't invalid but it... because the condition isn't valid or because the condition is invalid as you can see I even need a syntax checker for my own emails before I push the Send button. No wonder Red Dots don't work for me ;-( ___ 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: Script-only stacks [was: Re: Script Editor future]
On 30 Aug 2015, at 8:24 am, Peter TB Brett peter.br...@livecode.com wrote: I *think* Mark will be back in the office on Monday, so he'll probably see this exchange At the moment I usually treat normal stacks and script-only stacks as totally different things. I think of normal stacks as places for UI and trivial glue code, and script-only stacks as places for complex handler libraries and behaviours. They have different filenames too (.livecode vs .livecodescript). My instinct is that adding a way to switch a stack back and forth between normal and script-only isn't very intuitive, and could cause dire consequences as you suggest. On the other hand, having a *read only* scriptOnly property (or some equivalent) sounds like it could be pretty useful. The only use case I could think of for making it a writable property was for the standalone builder to support password protecting them by making them stacks but you could work around this by supporting password protection on script only stacks I guess or as Ali suggests just copy from one stack to the other, delete the original from memory and then set the name and save… Mind you we can do dangerous things with our code all the time so I don’t really think we need an nanny for this one... just some docs. Or just submit a PR on GitHub, that'll make sure it doesn't get forgotten about. ;-) I actually had some PRs that were forgotten about although I think both of them have now or will in the future at least become irrelevant because of widgets. Oops, sorry. I shouldn't let these things slip through the cracks. It's a lot easier now that there's a defined process for accepting contributions! The processes for community contributors and LiveCode employees are now pretty much the same -- the only two differences are that 1) we still can't accept binary stack changes directly (sorry :-/) and 2) employees don't have to sign the CLA. If you've got some PRs that have been overlooked about but which are still relevant, let me know and I'll try and make sure they get looked at... It was very early days. Well before Peter so don’t worry ;-) I think they were closed when the multiple develop branches thing happened and I didn’t bother to reopen because they already seemed no longer relevant unless there’s still folks that think custom controls have a future in a widgets world... ___ 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
Goodbye stsMLXEditor
Did lots of script editing in Textmate today via stsMXL plugin. Saved several times along the way, quit TextMate and Livecode. Next time I ran Livecode, all my edits were gone. Maybe it needed a final save or something but should have received warnings if so. Back to the IDE SE for me ___ 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: Goodbye stsMLXEditor
Peter Haworth wrote: Did lots of script editing in Textmate today via stsMXL plugin. Saved several times along the way, quit TextMate and Livecode. Next time I ran Livecode, all my edits were gone. Maybe it needed a final save or something but should have received warnings if so. Back to the IDE SE for me There's nothing magic about editing scripts. Whether the script is copied out of an object into a text field or into a temp file, the sequence is largely the same: an editScript message initiates the action, and a set script command puts the script back into the object it came from. It may well be that the very old stsMXL plugin could use an update, but for those who like using external editors I would encourage considering it as a useful starting point for a solution that can be every bit as robust as using a text field. Voodoo need not apply; just get a script and set a script, and what happens in between can be done by any means you prefer. If your edits were indeed put back into the objects you thought you were editing, and the stack those objects were in was indeed saved, something else went wrong. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
I think I found a very obscure bug. i created another palatte stack with my button... it works as expected. So there is was something different about my my utilities stack... well ...it has a field object on it Monitor-log this field had it's traversalOn set to true, autotab is off. even when I set the entire stack to mode 4 palette even just clicking on the background of the stack causes the top stack to lose it's selection.. if I delete that field OR set the traversalOn of the field to false then the problem disappears... behavior is as expected... Palette my utilities stack like this: on mouseUp set the defaultstack to the topStack put selectedChunk() end mouseUp now reports: char 468 to 488 of field 1 # correct... from the top stack go back to my utilities stack.. set the traversalOn of the field back to true and voila... even if the stack is palette mode, touching the stack will steal the focus back from the topStack. ergo: The very presence of a field on the card that has traversalOn=True will cause the palette stack to take the focus, even if your button is set to traversalOn=false.. Perhaps this is as expected the work around now is, in my toggle mode button on the utilities stack: on mouseup if the mode of this stack is 4 then toplevel this stack set the traversalOn of fld monitor-log to true else palette this stack set the traversalOn of fld monitor-log to false end if end mouseup I think what is happening is: even though Auto tab is off, if you have a field exposed on a card and go to that card the cursor jumps into the field... not matter what mode the stack is in... Should I report this? Richard Gaskin wrote: Works here, and given how much of the IDE relies on that sort of thing I'd be surprised it a regression survived release. Have you double-checked the palette mode, and the button's traversalOn? Brahmanathaswami wrote: 7.1.rc 1 I could have sworn this used to work: make stack # Call it no. 1 utilities create button set traversalON of the button to false on mouseUp set the defaultstack to the topStack put selectedChunk() end mouseUp set stack 1 to palette mode. go to stack 2 with text in a field selected in the utilities stack... click the button: even though the traversal is set to false for the button the text selection in the top stack field is lost /de-selected result char 1 to 0 of fld 1 ?? ___ 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
[ANN]SoCal LiveCode Meeting, Sept 3
The next meeting of the SoCal LiveCode User Group is coming up on Thursday, Sept 3 in Pasadena at 7PM. IMPORTANT: The meeting is being held at our new location, Du-par's Restaurant, on S. Lake Avenue near Cordova Street: Du-par's Pasadena, back room 214 S. Lake Ave. Pasadena, CA 91101 http://www.du-pars.com/dupars_locations.html Meeting details in the forum: http://forums.livecode.com/viewtopic.php?f=50t=25188 Trevor DeVore will be joining us that evening, so it should be an especially good time. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: More TopStack-DefaultStack Mysterious - TraveralOn (false) Selection lost?
Brahmanathaswami wrote: I think what is happening is: even though Auto tab is off, if you have a field exposed on a card and go to that card the cursor jumps into the field... not matter what mode the stack is in... Should I report this? I'm sure they're aware of it. The bigger question is: do we want to change it? As far back as I can remember we've had that behavior, presumably implemented as a convenience for developers since in most cases an editable field is for, well, editing, so when the window gets focus the first editable field gets focus. Sounds good in theory, but more than a few of us have had occasion to need to work around it, sometimes more easily done than others (the engine can be very insistent when it want to be). So we have to ask ourselves: do we want to have to explicitly script all field focus when a stack window gets focus? Will developers find that annoying to have to write, or feel liberated no longer having to write workaround when the current behavior isn't what they want? Personally I think there are bigger fish to fry (man, it would so cool if I could just copy and paste text on Linux, or have an option control with a label that could be read, or a text baseline on ostensibly standard buttons that's actually in a standard position), but maybe this is important to some... -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
