Re: out-of-the-blue codesigning error
Mike, Try this if you haven't already. Launch Xcode and open the Organizer window. Select Provisioning Profiles on the left, then hit the Refresh button on the lower right. This will sort of sync everything up between Apple's dev portal and your computer. After that's done, try building your app again, making sure there's a valid profile selected before doing so. Sometimes, at least in my case, refreshing the profiles will add/delete them, so in your standalone settings nothing will be selected. Not entirely sure if this will help, but it's worth a try. Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.com On Jul 11, 2013, at 5:28 PM, Mike Kerner mikeker...@roadrunner.com wrote: Is there some known way to debug this? I haven't seen anything on this list about it. Creating a new app gives the five-point signing error, now, too, and it seems that all of my apps have lost their link to their provisioning profiles. On Thu, Jul 11, 2013 at 6:55 PM, Randy Hengst iowahen...@mac.com wrote: Mike, The only time that's happened to me is when I didn't change to the correct profile when I built the standalone in LC. That was the problem even when I knew I used the right one. be well, randy - On Jul 11, 2013, at 5:35 PM, Scott Rossi sc...@tactilemedia.com wrote: Not sure if this is your issue, but FWIW, trying to load/transfer a newly built app to a device always fails on my system unless I use the AppResigner tool that was mentioned on the list a ways back. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 7/11/13 3:22 PM, Mike Kerner mikeker...@roadrunner.com wrote: An app that I have been using and deploying to my team for months is now failing to build with codesigning failed with aps-environment development I checked the certs in keychain and in xcode and at apple's developer portal, and nothing seems to be expired or otherwise out of the ordinary. So any ideas on what to try next? -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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
[OT] Ouch
http://www.bbc.co.uk/news/technology-23285642 ___ 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: out-of-the-blue codesigning error
thanks, Chris, but that didn't fix it, either. It's really weird - even the wildcard certificate doesn't work for a brand-spaking new stack with nothing else attached to it. On Fri, Jul 12, 2013 at 10:34 AM, Chris Sheffield cmsheffi...@icloud.comwrote: Mike, Try this if you haven't already. Launch Xcode and open the Organizer window. Select Provisioning Profiles on the left, then hit the Refresh button on the lower right. This will sort of sync everything up between Apple's dev portal and your computer. After that's done, try building your app again, making sure there's a valid profile selected before doing so. Sometimes, at least in my case, refreshing the profiles will add/delete them, so in your standalone settings nothing will be selected. Not entirely sure if this will help, but it's worth a try. Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.com On Jul 11, 2013, at 5:28 PM, Mike Kerner mikeker...@roadrunner.com wrote: Is there some known way to debug this? I haven't seen anything on this list about it. Creating a new app gives the five-point signing error, now, too, and it seems that all of my apps have lost their link to their provisioning profiles. On Thu, Jul 11, 2013 at 6:55 PM, Randy Hengst iowahen...@mac.com wrote: Mike, The only time that's happened to me is when I didn't change to the correct profile when I built the standalone in LC. That was the problem even when I knew I used the right one. be well, randy - On Jul 11, 2013, at 5:35 PM, Scott Rossi sc...@tactilemedia.com wrote: Not sure if this is your issue, but FWIW, trying to load/transfer a newly built app to a device always fails on my system unless I use the AppResigner tool that was mentioned on the list a ways back. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 7/11/13 3:22 PM, Mike Kerner mikeker...@roadrunner.com wrote: An app that I have been using and deploying to my team for months is now failing to build with codesigning failed with aps-environment development I checked the certs in keychain and in xcode and at apple's developer portal, and nothing seems to be expired or otherwise out of the ordinary. So any ideas on what to try next? -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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: out-of-the-blue codesigning error
At times I have had to delete an app before updating it, especially when there are provisioning changes. All day yesterday I read the subject to be about co-designing rather than code-signing, a different interesting topic. Dar On Jul 12, 2013, at 9:11 AM, Mike Kerner wrote: thanks, Chris, but that didn't fix it, either. It's really weird - even the wildcard certificate doesn't work for a brand-spaking new stack with nothing else attached to it. On Fri, Jul 12, 2013 at 10:34 AM, Chris Sheffield cmsheffi...@icloud.comwrote: Mike, Try this if you haven't already. Launch Xcode and open the Organizer window. Select Provisioning Profiles on the left, then hit the Refresh button on the lower right. This will sort of sync everything up between Apple's dev portal and your computer. After that's done, try building your app again, making sure there's a valid profile selected before doing so. Sometimes, at least in my case, refreshing the profiles will add/delete them, so in your standalone settings nothing will be selected. Not entirely sure if this will help, but it's worth a try. Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.com On Jul 11, 2013, at 5:28 PM, Mike Kerner mikeker...@roadrunner.com wrote: Is there some known way to debug this? I haven't seen anything on this list about it. Creating a new app gives the five-point signing error, now, too, and it seems that all of my apps have lost their link to their provisioning profiles. On Thu, Jul 11, 2013 at 6:55 PM, Randy Hengst iowahen...@mac.com wrote: Mike, The only time that's happened to me is when I didn't change to the correct profile when I built the standalone in LC. That was the problem even when I knew I used the right one. be well, randy - On Jul 11, 2013, at 5:35 PM, Scott Rossi sc...@tactilemedia.com wrote: Not sure if this is your issue, but FWIW, trying to load/transfer a newly built app to a device always fails on my system unless I use the AppResigner tool that was mentioned on the list a ways back. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 7/11/13 3:22 PM, Mike Kerner mikeker...@roadrunner.com wrote: An app that I have been using and deploying to my team for months is now failing to build with codesigning failed with aps-environment development I checked the certs in keychain and in xcode and at apple's developer portal, and nothing seems to be expired or otherwise out of the ordinary. So any ideas on what to try next? -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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
Re: Array glitch
Terry, I tried your script here and got the same error as you in LC 5.5.4 and LC Community 6.0 on a Windows 8 box. I use strict compile mode but declaring the tSimpleArray variable made no difference. I also put the seconds into a variable, tKey, put zero into tSimpleArray[tKey], then did a put tSImpleArray[tKey] and the message box happily showed zero. My guess is that it's a problem within the debugger while formatting the value of the key for display and nothing to do with regular access of the array key contents A quick search of the QCC turned up a couple of debug/array abort issues but none that match something as simple as this situation, so you're best bet to get to the bottom of it is file a bug report. Pete lcSQL Software http://www.lcsql.com On Thu, Jul 11, 2013 at 6:31 PM, Terry Dennis teden...@softwaredetails.comwrote: Mark: re: test script in a button in a *new stack*? Been there, done that. As I noted in a prior email, it occurred ... 3) in an entirely new stack after exiting and re-entering LC Perhaps I'm being paranoid and I shouldn't worry about it. If I rely on that assumption as a basis for using seconds as my data access scheme, it's likely I will regret it somewhere down the road. I think Murphy is in my family tree. I've considered using the difference between seconds and the start of the decade, or the start of the century, as my array key. Then, adjust it when necessary. But, until I can be reasonably confident I won't run into the same type of problem with a different value, I'm reluctant to rework my logic to use that scheme. I suppose I could spend a bunch of time running a zillion tests with different values until I come across the value that breaks it. Then we would have something for the LC guys to work on. I'll get back to you in a couple of years to let you know the results of my tests. ;-) Of course, it could be it has nothing whatsoever to do with the value of the key ... which is why I didn't think seconds would break it. Loop: See recursive Recursive: See loop Terry __**_ 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-livecodehttp://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: out-of-the-blue codesigning error
Dar- Friday, July 12, 2013, 8:23:47 AM, you wrote: All day yesterday I read the subject to be about co-designing rather than code-signing, a different interesting topic. LOL. I have the same problem when I read about resigning. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Array glitch
Pete- Friday, July 12, 2013, 9:21:46 AM, you wrote: Terry, I tried your script here and got the same error as you in LC 5.5.4 and LC Community 6.0 on a Windows 8 box. Aha! A second confirmation. Maybe it's just a Windows thing? -- -Mark Wieder mwie...@ahsoftware.net ___ 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
positioning stacks off screen in Linux
One of the commonly suggested methods of hiding stacks is setting their location to something that places them out of the view window. This is not working correctly here under openSUSE/KDE/KWin. A stack's location is constrained to the available viewport unless it has been previously dragged and placed so that some part of it past the screen edge. Once that is done, a stack can be positioned anywhere outside the viewport until it is completely within it and we return to our original problem. In order for any part of a stack to be positioned outside the viewport, some part of it must already appear beyond a screen edge. This does not happen under Windows. Do users of other Linux distros/DEs/window managers find this same behavior? Warren ___ 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
Chained Behaviors
Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. Pete lcSQL Software http://www.lcsql.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: Array glitch
Could be - my Mac is in hospital having hard drive replacement surgery so can't test on OSX right now. Pete lcSQL Software http://www.lcsql.com On Fri, Jul 12, 2013 at 9:56 AM, Mark Wieder mwie...@ahsoftware.net wrote: Pete- Friday, July 12, 2013, 9:21:46 AM, you wrote: Terry, I tried your script here and got the same error as you in LC 5.5.4 and LC Community 6.0 on a Windows 8 box. Aha! A second confirmation. Maybe it's just a Windows thing? -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
Hi Peter, Am 12.07.2013 um 19:04 schrieb Peter Haworth p...@lcsql.com: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. I second this! :-) Pete lcSQL Software http://www.lcsql.com Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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: Array glitch
Pete- Friday, July 12, 2013, 10:06:34 AM, you wrote: Could be - my Mac is in hospital having hard drive replacement surgery so can't test on OSX right now. Ouch! That's right - I forgot about that. Hope it won't be long. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: mApp LC6.1 crash
Monte, Do you have a fix? workaround? Tom -- Tom McGrath III http://lazyriver.on-rev.com mcgra...@mac.com On Jul 9, 2013, at 4:20 PM, Monte Goulding mo...@sweattechnologies.com wrote: On 10/07/2013, at 12:45 AM, Thomas McGrath III mcgra...@mac.com wrote: I have been trying to test a sample stack in 6.1 Build 2005 for iOS simulator and it just crashes immediately when selecting Test. This stack works perfectly in 5.5.5 It uses mAPP Mobile Application Framework Crashed Thread: 0 Dispatch queue: com.apple.main-thread That's the one ;-) Note that you will probably need to fix the behavior of the stack and delete the stack named mAppLibrary the seconds... -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. It obviates the switch statement. We could take this question one step back and ask why we'd want behaviors at all, when we could just use frontScripts with switch statements instead. But that thought experiment (hopefully) makes the case for behaviors clear. Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Array glitch
Mark- Friday, July 12, 2013, 9:56:18 AM, I wrote: Aha! A second confirmation. Maybe it's just a Windows thing? Still works for me here on OSX 10.6 with LC 4.6.4, 5.5.3, and LC Community 6. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
On 7/12/13 12:04 PM, Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. I needed chained behaviors a while ago before they were available, and was required to copy duplicate sections of scripts into each of several behaviors. If I get time I'll go back and chain them now that it is available. Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp The mouseDown handler was semi-lengthy and I would have prefered not repeating it in each behavior script. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Chained Behaviors
Date: Fri, 12 Jul 2013 10:58:29 -0700 From: ambassa...@fourthworld.com To: use-livecode@lists.runrev.com Subject: Re: Chained Behaviors Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. Richard... I hear what you say, but does an xTalk language need to go down this road ?... or to perhaps put a direct way... Should an xTalk language be going down this road ?... What I am worried about is that there are a lot of people jumping on the 'open source' bandwagon... wanting to change things for what they see as improvement whilst completely forgetting that it is simplicity not complexity that has got xTalk where it is today... John Craig and I have debated this very point for hours... but all that has come outof our discussions is that we agree to disagree... Dixie ___ 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: Chained Behaviors
I think the strength of livecode is that it can build very simple and also very complex things. I wish I was more familiar with behaviors and their use cases (out of all the stuff I build every day in livecode I have never implemented a behavior script I have written) but I imagine this is similar to method chaining in other languages? Also, Does someone have that killer example stack or article/lesson on behaviors that sums it all up? Andrew On Fri, Jul 12, 2013 at 1:48 PM, John Dixon dixo...@hotmail.co.uk wrote: Date: Fri, 12 Jul 2013 10:58:29 -0700 From: ambassa...@fourthworld.com To: use-livecode@lists.runrev.com Subject: Re: Chained Behaviors Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. Richard... I hear what you say, but does an xTalk language need to go down this road ?... or to perhaps put a direct way... Should an xTalk language be going down this road ?... What I am worried about is that there are a lot of people jumping on the 'open source' bandwagon... wanting to change things for what they see as improvement whilst completely forgetting that it is simplicity not complexity that has got xTalk where it is today... John Craig and I have debated this very point for hours... but all that has come outof our discussions is that we agree to disagree... Dixie ___ 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 -- Regards, Andrew Kluthe and...@ctech.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: Chained Behaviors
John, in my opinion, behaviors is simplicity. You don't have to deal with the name of the buttons (for example), just use me. It is completely on the road of a xTalk language. Same things for nested behaviors. Jacques Clavell Le 12 juil. 2013 à 20:48, John Dixon dixo...@hotmail.co.uk a écrit : Date: Fri, 12 Jul 2013 10:58:29 -0700 From: ambassa...@fourthworld.com To: use-livecode@lists.runrev.com Subject: Re: Chained Behaviors Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. Richard... I hear what you say, but does an xTalk language need to go down this road ?... or to perhaps put a direct way... Should an xTalk language be going down this road ?... What I am worried about is that there are a lot of people jumping on the 'open source' bandwagon... wanting to change things for what they see as improvement whilst completely forgetting that it is simplicity not complexity that has got xTalk where it is today... ___ 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: Chained Behaviors
Jaques... I understand 'behaviors', I use them quite a lot of the time... I just don't see the need to continue with the 'chain' in xTalk... I think that this is the thin end of the wedge... changing things using the argument, 'well, that's what happens in other languages... so what ?! Dixie Subject: Re: Chained Behaviors From: jacques.cla...@gmail.com Date: Fri, 12 Jul 2013 21:07:55 +0200 To: use-livecode@lists.runrev.com John, in my opinion, behaviors is simplicity. You don't have to deal with the name of the buttons (for example), just use me. It is completely on the road of a xTalk language. Same things for nested behaviors. Jacques Clavell ___ 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
unicode font names
Hi, Can anybody set unicode font names of the fontNames to the menu items of pulldown menu? Thanks, -- Kenji Kojima / 小島健治 http://www.kenjikojima.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: Chained Behaviors
John Dixon wrote: Richard... I hear what you say, but does an xTalk language need to go down this road ?... or to perhaps put a direct way... Should an xTalk language be going down this road ?... What I am worried about is that there are a lot of people jumping on the 'open source' bandwagon... wanting to change things for what they see as improvement whilst completely forgetting that it is simplicity not complexity that has got xTalk where it is today... Speaking only for myself, what distinguishes LiveCode from the legacy of most earlier xTalks is its willingness to grow. Associative arrays, touch UIs, sockets, repeat for each, is among, and perhaps more than anyone would want me to enumerate here -- all introduced to the xTalk world in MetaCard/Revolution/LiveCode. And behaviors too. But behaviors limited to a single level are almost a tease, as limited as comparing HyperCard's backgrounds to LiveCode's groups. True, HyperCard was easy to learn precisely because of these limitations. Few things are as overwhelming as holding a paintbrush in your hand facing a canvas with infinite bounds. HC put a relatively small frame on the canvas it let us work with, and in its way those limitations were indeed liberating. But as we learn and grow over the years, our desires for what we want to do with our software grow along with them. For all the fond memories we have of HyperCard, I doubt few would find it satisfying to work with a single monochrome window with few control types, no color, no vector graphics, no arrays, etc. I hear what you're saying about the risk of becoming too complex, and I agree we should evaluate such proposed extensions very carefully. But like arrays, nested behaviors are purely optional: those who don't want them are free to never use them, while those who crave them at last have them. Extensions like these preserve the core flavor of the language, while extending it in useful ways at the same time. Key to this delicate balancing act is discretion, knowing when to say no. Having once had a disagreement with Mark Waddingham over a language design issue, my respect for his good judgment in this regard was only amplified by that momentary conflict. In the end what I learned is that he's deeply passionate about preserving the essence of xTalk, and as long as there's a mother ship playing the role of arbiter of such decisions, I feel we can relax with the confidence that we're in good hands. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Array glitch
Just to confirm, you can get into the debugger variables tab and expand the array to show its key and value? Pete lcSQL Software http://www.lcsql.com On Fri, Jul 12, 2013 at 11:23 AM, Mark Wieder mwie...@ahsoftware.netwrote: Mark- Friday, July 12, 2013, 9:56:18 AM, I wrote: Aha! A second confirmation. Maybe it's just a Windows thing? Still works for me here on OSX 10.6 with LC 4.6.4, 5.5.3, and LC Community 6. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
Richard I hear what you're saying about the risk of becoming too complex, and I agree we should evaluate such proposed extensions very carefully. On this we agree... with emphasis on 'very carefully'... In the end what I learned is that he's deeply passionate about preserving the essence of xTalk, and as long as there's a mother ship playing the role of arbiter of such decisions, I feel we can relax with the confidence that we're in good hands. I really do hope so... Dixie ___ 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: Chained Behaviors
On Fri, Jul 12, 2013 at 10:58 AM, Richard Gaskin ambassa...@fourthworld.com wrote: t obviates the switch statement. We could take this question one step back and ask why we'd want behaviors at all, when we could just use frontScripts with switch statements instead. But that thought experiment (hopefully) makes the case for behaviors clear. Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. I'm definitely not against behaviors themselves, just trying to understand the value of chaining them. Pete lcSQL Software http://www.lcsql.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: Chained Behaviors
On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay jac...@hyperactivesw.comwrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Pete lcSQL Software http://www.lcsql.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: Chained Behaviors
Because each sprite would then have its own script, which would be identical to all the other sprites' scripts. Then if a change were needed, you'd have to go in and modify each additional script. Quite a nightmare if you have hundreds of them.. Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.com On Jul 12, 2013, at 1:47 PM, Peter Haworth p...@lcsql.com wrote: On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay jac...@hyperactivesw.comwrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Pete lcSQL Software http://www.lcsql.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: Chained Behaviors
I meant to say individual, not additional. Sorry 'bout that. On Jul 12, 2013, at 1:53 PM, Chris Sheffield cmsheffi...@icloud.com wrote: Because each sprite would then have its own script, which would be identical to all the other sprites' scripts. Then if a change were needed, you'd have to go in and modify each additional script. Quite a nightmare if you have hundreds of them.. Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.com On Jul 12, 2013, at 1:47 PM, Peter Haworth p...@lcsql.com wrote: On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay jac...@hyperactivesw.comwrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Pete lcSQL Software http://www.lcsql.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 ___ 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: Chained Behaviors
On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi sc...@tactilemedia.comwrote: have built a system that uses one behavior for a wide range of controls using switch statements, and the higher the number of controls you have to support, the more complex and messier the code gets. Chained behaviors gives you another option to modularize your code. Good point Scott. Switch statements definitely get messy when they have a large number of case statements within them. I think this is coming down to the fact that I personally haven't come across a situation where chained behaviors would have been useful or there wasn't a perfectly acceptable alternative, at least for my programming style. I think one of the things that concerns me is the relative invisibility of behaviors, resulting in it sometimes being hard to track down where things happen, especially if you're looking at someone else's code. Heck, the IDE Inspector doesn't even show a behavior field for some object types so tracking down the fact that a behavior is in effect is hard enough at a single level never mind multiple levels. At least if you write a common handler and call it from each control's script, you can see right in front of you. Pete lcSQL Software http://www.lcsql.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: out-of-the-blue codesigning error
It's so weird that my existing apps, the ones that have zero changes to them, won't go now, either. On Fri, Jul 12, 2013 at 12:53 PM, Mark Wieder mwie...@ahsoftware.netwrote: Dar- Friday, July 12, 2013, 8:23:47 AM, you wrote: All day yesterday I read the subject to be about co-designing rather than code-signing, a different interesting topic. LOL. I have the same problem when I read about resigning. -- -Mark Wieder mwie...@ahsoftware.net ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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: Chained Behaviors
On 07/12/2013 08:58 PM, Richard Gaskin wrote: Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. It obviates the switch statement. And what, pray tell, is wrong with switch statements? My main thing works on switch statements with nary a backward glance. Richmond. We could take this question one step back and ask why we'd want behaviors at all, when we could just use frontScripts with switch statements instead. But that thought experiment (hopefully) makes the case for behaviors clear. Nested behaviors simply extend the value of such a mechanism, at long last giving xTalk one of the most valuable aspects of OOP: subclasses. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: unicode font names
On 07/12/2013 10:16 PM, in...@kenjikojima.com wrote: Hi, Can anybody set unicode font names of the fontNames to the menu items of pulldown menu? Thanks, -- Kenji Kojima / 小島健治 http://www.kenjikojima.com/ Well, I work with Unicode fonts all the time, and find that on mouseDown put the fontnames into me end mouseDown puts all the names of the fonts on my system into my pullDown menu; what is does (and maybe this is your problem) is that it lists the fonts by their Latin names, rather than their names in the language they are used for. For the sake of argument, an Arabic font may be listed as Arabic4 rather than a name in Arabic script. 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: Chained Behaviors
On 7/12/13 2:47 PM, Peter Haworth wrote: On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay jac...@hyperactivesw.comwrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Well, there are four different behaviors (so far,) applied to hundreds of objects spread across dozens of stacks. If I needed to change anything, I'd be in there for weeks or I'd have to script an auto-scripter. Also, the bulk of all those repetitions would unnecessarily increase the stack size. One of the mouseUp behaviors is 200 lines long. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Chained Behaviors
On 07/12/2013 10:43 PM, John Dixon wrote: Richard I hear what you're saying about the risk of becoming too complex, and I agree we should evaluate such proposed extensions very carefully. On this we agree... with emphasis on 'very carefully'... In the end what I learned is that he's deeply passionate about preserving the essence of xTalk, and as long as there's a mother ship playing the role of arbiter of such decisions, I feel we can relax with the confidence that we're in good hands. I really do hope so... Dixie When I was 4 years old (1966) an aunt of mine sent me a box full of Lego; this meant blocks and plates, the next year she sent me some wheels, windows and doors, the year after that she sent me some roof tiles, the year after that she died. - Years later (1982) I went to buy some more Lego . . . and found that there was a plethora of funny shaped bits that, while looking as if they allowed you greater creativity, actually restricted the choices of what you could make with them. - God forgive me, but I wonder if my aunt didn't die at just the right time. I rest my case. 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: Chained Behaviors
Richmond wrote: On 07/12/2013 08:58 PM, Richard Gaskin wrote: Peter Haworth wrote: Has anyone got any real world examples of the benefits of the new chained behaviors feature? I just read the latest newsletter article about them and while I understand the concept, I didn't see benefit in the example scenario over a single behavior with some common logic and a switch statement to handle the logic specific to each sprite. It obviates the switch statement. And what, pray tell, is wrong with switch statements? Nothing. Use 'em where you like 'em. OOP is a code design issue. There are countless arguments around the 'net about the benefits of OOP, and those are probably better than any I could come up with because I find myself here in a cognitive bind: I'm unable to understand how one level of behaviors can be seen as valuable but multiple levels not seen as adding even more value. But that's just me. Whether I can explain why I like 'em or not, I look forward to using 'em. And if instead you prefer one long script with conditionals, you can enjoy that too. Everyone has what they want here. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Chained Behaviors
Ah OK, that makes sense. I had the impression that each sprite needed mouseUp logic that was unique to it. I think I'm now seeing the usefulness of this. I'm thinking there might be a spot for a utility that, for any given control, lists the message handlers it uses and where they reside. Pete lcSQL Software http://www.lcsql.com On Fri, Jul 12, 2013 at 1:31 PM, J. Landman Gay jac...@hyperactivesw.comwrote: On 7/12/13 2:47 PM, Peter Haworth wrote: On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay jac...@hyperactivesw.com**wrote: Remember that behaviors are not a single handler, they are whole scripts. I have several sprites that require different behaviors on mouseUp but they all have the same behaviors on mouseDown. With a chained behavior, I could have placed the mouseDown handler into the top of the chain and different mouseUp handlers in each separate behavior script underneath that: on mouseDown doDownStuff end mouseDown /\ on mouseUp on mouseUp doBehavior1 doBehavior2 end mouseUp end mouseUp OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Well, there are four different behaviors (so far,) applied to hundreds of objects spread across dozens of stacks. If I needed to change anything, I'd be in there for weeks or I'd have to script an auto-scripter. Also, the bulk of all those repetitions would unnecessarily increase the stack size. One of the mouseUp behaviors is 200 lines long. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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-livecodehttp://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: Chained Behaviors
On Fri, Jul 12, 2013 at 12:36 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Having once had a disagreement with Mark Waddingham over a language design issue, my respect for his good judgment in this regard was only amplified by that momentary conflict. I remember a while back you mentioned the need for a Community Manager (or something similar) in the open source world. Is Mark that person then? Pete lcSQL Software http://www.lcsql.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: Chained Behaviors
For anyone who hasn't played with behaviors yet, try scripting something like this without them: Create a stack. Put ten small images on the card, each with a unique name. These are the sprites. The stack script should already have its own mouseDown and mouseUp handlers that do something unrelated to the sprites. Sprite handlers: On mousedown: Every image plays a click sound Every image says its name On mouseup: Images 1-3 move to the top left corner Images 4-6 change their ink Images 7-9 play an additional sound file Image 10 beeps I know how I'd do it the old way. My existing mouseUp and mouseDown handlers would need to branch to accomodate what was being clicked; do one thing if it's a sprite, something else if it's a regular button. I'd assign a custom property to each type of sprite, check that to determine the correct behavior, and write a long switch structure with all the responses in it. Alternately, every sprite would need at least a mouseDown and mouseUp handler that at least called another handler in the stack. Now try it with chained behaviors. No branching, no altering existing mouse handlers, no big switch statements, no custom property, no sprite scripts, all code in an isolated instance that does not interfere with any other code. It's as if every sprite is all alone on the card, running its own little script with nothing else in the way. And all I had to do is assign the behavior; the image itself has no properties or scripts. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: unicode font names
Richmond, I tried many times same script all day, but could not make. Strange. Anyway I could. Thanks. on mouseDown if the platform is MacOS then set the textFont of me to Osaka else set the textFont of me to Tahoma end if get the fontNames repeat for each line tLine in it if the fontLanguage of tLine is japanese then put tLine cr after tFontNames end if end repeat sort tFontNames delete char -1 of tFontNames set the text of me to tFontNames end mouseDown on menuPick pItemName set the textFont of fld nihongo to pItemName end menuPick -- Kenji Kojima / 小島健治 http://www.kenjikojima.com/ On Jul 12, 2013, at 4:28 PM, Richmond wrote: On 07/12/2013 10:16 PM, in...@kenjikojima.com wrote: Hi, Can anybody set unicode font names of the fontNames to the menu items of pulldown menu? Thanks, -- Kenji Kojima / 小島健治 http://www.kenjikojima.com/ Well, I work with Unicode fonts all the time, and find that on mouseDown put the fontnames into me end mouseDown puts all the names of the fonts on my system into my pullDown menu; what is does (and maybe this is your problem) is that it lists the fonts by their Latin names, rather than their names in the language they are used for. For the sake of argument, an Arabic font may be listed as Arabic4 rather than a name in Arabic script. 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: Chained Behaviors
Hi Pete: FWIW, a behavior script is not much different than using a library script, or front/backScript. It's a block of code that executed along the way of the message path but stays local to the object it is assigned to. In fact, one could *almost* say that behaviors are in some cases more apparent the aforementioned scripts because (for the moment) behavior scripts can only be placed in buttons, while front/backScripts can exist in most any control. Another thing about behaviors is they offer a few special features, such as their connection to groups. When a behavior is applied to a group, you can, for example, continually track the resizeControl message while the group is being resized. With other objects, the control receives the message only after the resize event is completed. Agreed that the display/management of behaviors in the IDE could be improved, but the RunRev guys are working on updating the IDE, so maybe we'll see something new there. In the end, as Richard stated, no one is being forced to use behaviors, or chained behaviors. Use them or ignore them as you see fit. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 7/12/13 1:04 PM, Peter Haworth p...@lcsql.com wrote: On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi sc...@tactilemedia.comwrote: have built a system that uses one behavior for a wide range of controls using switch statements, and the higher the number of controls you have to support, the more complex and messier the code gets. Chained behaviors gives you another option to modularize your code. Good point Scott. Switch statements definitely get messy when they have a large number of case statements within them. I think this is coming down to the fact that I personally haven't come across a situation where chained behaviors would have been useful or there wasn't a perfectly acceptable alternative, at least for my programming style. I think one of the things that concerns me is the relative invisibility of behaviors, resulting in it sometimes being hard to track down where things happen, especially if you're looking at someone else's code. Heck, the IDE Inspector doesn't even show a behavior field for some object types so tracking down the fact that a behavior is in effect is hard enough at a single level never mind multiple levels. At least if you write a common handler and call it from each control's script, you can see right in front of you. Pete lcSQL Software http://www.lcsql.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
Sockets on mobile…at last!
Monte, I just want to thank you for completing this external. We have been using it every day for the last few days on iPads. Our iPads can now communicate directly with our desktops. It is truly amazing to see it all working so well. If you are looking for sockets on iOS, Monte has what you need. Long live these and other amazing 3rd party efforts to improve our programming lives. Best regards, Mark Talluto canelasoftware.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: Sockets on mobile…at last!
On 13/07/2013, at 7:51 AM, Mark Talluto use...@canelasoftware.com wrote: I just want to thank you for completing this external. We have been using it every day for the last few days on iPads. Our iPads can now communicate directly with our desktops. It is truly amazing to see it all working so well. If you are looking for sockets on iOS, Monte has what you need. Long live these and other amazing 3rd party efforts to improve our programming lives. Thanks Mark, I'm glad it's doing the job for you. Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
John- Friday, July 12, 2013, 12:12:45 PM, you wrote: I understand 'behaviors', I use them quite a lot of the time... I just don't see the need to continue with the 'chain' in xTalk... I You don't *need* to chain them at all. Just continue working the way you do and nothing changes. I think it's roughly equivalent to the question of why would I want to put code in the stack script? Everything works fine if I just copy and paste all this code into each of 20 buttons... The idea that you can put code in an object or in a group or in a card or in a stack or... is the same sort of inheritance that behaviors, or nested behaviors, bring to the table. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
Monte, If you read my later post, you'd see that I get the issue with the mouseUp handlers, just wasn't clear from Jacque's original diagram. As for the what's in it for me issue, that wasn't my question. I simply asked for real life examples of the practical use of chained behaviors since I wasn't seeing anything particularly useful in the simple newsletter example. Now the good people on this list have enlightened me and I see the use cases. Although I don't have a personal need for chained behaviors that I can think of right now, I will certainly be aware of them for future projects. Pete lcSQL Software http://www.lcsql.com On Fri, Jul 12, 2013 at 1:38 PM, Monte Goulding mo...@sweattechnologies.com wrote: On 13/07/2013, at 5:47 AM, Peter Haworth p...@lcsql.com wrote: OK, good example, thanks. I have to ask, though, why not have the unique mouseUp handlers in the sprite scripts and a behavior script for the common mouseDown handler? Because that would mean replication and more maintenance if there's a lot of sprites with the same handler. Here's an idea... why don't we put all our code into big switch statements in the mainstack script... that sounds like fun ;-) I've got another use case. The mApp framework is a behavior script for the mainstack of the app. It has a small amount of code that's only in there for development support... standalone building, drag and drop of images onto the app etc. This code really shouldn't be in the built app. With chained behaviors I can put it in a support behavior that doesn't get's copied to the stackfile during the build. Most of my behaviors are based on the same boilerplate template so there's lots of common code. If I could move most of that to a parent behavior I'd be very happy to do so because any fixes would be applied to all... Like Richard I've been waiting for this for years. One of my biggest gripes about LiveCode is that it's sometimes hard to avoid replicating the same code all over the place. If you need to change something then you need to change it everywhere. It's easy to introduce bugs there because you miss one or two spots where you didn't change the code. Whenever there's a significant new feature added to LiveCode there's always a certain about of what's in it for me going on on this list. People want the things they need to be higher priority. Well the good news on this one is it was all implemented when behaviors were first introduced and was just #ifdefed out. So it was a money for jam investment as far as RunRev was concerned. It was just a case of out of sight out of mind until a few of us spotted the tantalisingly named FEATURE_INHERITED_PARENTSCRIPTS ... There seems to be a certain element that believe that Mark Waddingham is the only thing holding back a tide of open source contributors that want to turn LiveCode into a low level language and ruin your platform. It's just plain untrue and I think it's a very harmful attitude to have. Why not stop and think what might motivate someone to put their spare time into working on the engine? If anything the open source move gives everyone a chance to become involved in feature development discussions and implementations to ensure all the Xtalk ducks are in a row. Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
Monte- Friday, July 12, 2013, 1:38:06 PM, you wrote: a money for jam investment as far as RunRev was concerned. It was just a case of out of sight out of mind until a few of us spotted the tantalisingly named FEATURE_INHERITED_PARENTSCRIPTS ... Well, to be fair about that, the feature was implemented but never extensively tested, and certainly not enough to release it as a finished feature. So it was left as a message to future developers. Then people from the future came along and said whoa! look at that!. If anything the open source move gives everyone a chance to become involved in feature development discussions and implementations to ensure all the Xtalk ducks are in a row. Absolutely. That's why the discussions going on over at the web forum are so important. I think we need to talk about these things as or before they get implemented, so that we can brainstorm about possible pitfalls, dead ends, etc. I'm currently having an argument with Mark about a certain feature, and I have no doubt that he'll win, but I think I still have some valid points to make before I'm ready to give in. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Array glitch
Pete- Friday, July 12, 2013, 12:39:51 PM, you wrote: Just to confirm, you can get into the debugger variables tab and expand the array to show its key and value? Yep. That was my test case. Hit the breakpoint, drop down to the variables tab, expand the array, see the zero. And the seconds. Do it a few times to make sure the seconds key changes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
On 13/07/2013, at 8:40 AM, Peter Haworth p...@lcsql.com wrote: If you read my later post, you'd see that I get the issue with the mouseUp handlers, just wasn't clear from Jacque's original diagram. Right... I wrote that before Jacque's second answer came in and your response to it. As for the what's in it for me issue, that wasn't my question. I simply asked for real life examples of the practical use of chained behaviors since I wasn't seeing anything particularly useful in the simple newsletter example. Now the good people on this list have enlightened me and I see the use cases. Although I don't have a personal need for chained behaviors that I can think of right now, I will certainly be aware of them for future projects. I was responding to the thread in general there not necessarily your original post. Sorry for the confusion. -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
On 13/07/2013, at 8:52 AM, Mark Wieder mwie...@ahsoftware.net wrote: whoa! look at that!. Ah.. happy memories ;-) If anything the open source move gives everyone a chance to become involved in feature development discussions and implementations to ensure all the Xtalk ducks are in a row. Absolutely. That's why the discussions going on over at the web forum are so important. I think we need to talk about these things as or before they get implemented, so that we can brainstorm about possible pitfalls, dead ends, etc. I'm currently having an argument with Mark about a certain feature, and I have no doubt that he'll win, but I think I still have some valid points to make before I'm ready to give in. Yes your alternate languages on linux implementation and thread is a good example of how just because someone has implemented something and is prepared to contribute it doesn't mean it's definitely going in the engine. Basically nothing gets in the engine unless it goes through Mark and he thinks it's both a good thing and ready. -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
Peter Haworth wrote: I remember a while back you mentioned the need for a Community Manager (or something similar) in the open source world. Is Mark that person then? As the number of contributors grows, the role of Community Manager can be expected to outgrow Mark's availability, so I believe RunRev plans on having someone to handle that soon. But in the meantime, when it comes to stewarding the code base, right now Mark is effectively serving that role. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Array glitch
OK, all works fine for me too on a Mac so it does look like it's a Windows problem (maybe Linux too?) Pete lcSQL Software http://www.lcsql.com On Fri, Jul 12, 2013 at 3:54 PM, Mark Wieder mwie...@ahsoftware.net wrote: Pete- Friday, July 12, 2013, 12:39:51 PM, you wrote: Just to confirm, you can get into the debugger variables tab and expand the array to show its key and value? Yep. That was my test case. Hit the breakpoint, drop down to the variables tab, expand the array, see the zero. And the seconds. Do it a few times to make sure the seconds key changes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
Richard Gaskin wrote... As the number of contributors grows, the role of Community Manager can be expected to outgrow Mark's availability, so I believe RunRev plans on having someone to handle that soon. But in the meantime, when it comes to stewarding the code base, right now Mark is effectively serving that role. Then let's hope that the appointed person is steeped in the xTalk philosophy... perhaps Mr Bill Atkinson would be the perfect 'steward'...:-) ___ 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: positioning stacks off screen in Linux
On 07/12/2013 12:00 PM, Warren Samples wrote: One of the commonly suggested methods of hiding stacks is setting their location to something that places them out of the view window. This is not working correctly here under openSUSE/KDE/KWin. A stack's location is constrained to the available viewport unless it has been previously dragged and placed so that some part of it past the screen edge. Once that is done, a stack can be positioned anywhere outside the viewport until it is completely within it and we return to our original problem. In order for any part of a stack to be positioned outside the viewport, some part of it must already appear beyond a screen edge. This does not happen under Windows. Do users of other Linux distros/DEs/window managers find this same behavior? Warren Trying this is Mint 9 in VirtualBox is even worse. Stacks cannot be moved completely out of view no matter what I try. Anyone else? ___ 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: Sockets on mobile…at last!
So the Android version will be next, right? On Jul 12, 2013 6:13 PM, Monte Goulding mo...@sweattechnologies.com wrote: On 13/07/2013, at 7:51 AM, Mark Talluto use...@canelasoftware.com wrote: I just want to thank you for completing this external. We have been using it every day for the last few days on iPads. Our iPads can now communicate directly with our desktops. It is truly amazing to see it all working so well. If you are looking for sockets on iOS, Monte has what you need. Long live these and other amazing 3rd party efforts to improve our programming lives. Thanks Mark, I'm glad it's doing the job for you. Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: positioning stacks off screen in Linux
Warren- Friday, July 12, 2013, 5:18:12 PM, you wrote: Trying this is Mint 9 in VirtualBox is even worse. Stacks cannot be moved completely out of view no matter what I try. Anyone else? Yep. Verified here on linux mint 14. -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chained Behaviors
On 7/12/13 6:08 PM, Monte Goulding wrote: Basically nothing gets in the engine unless it goes through Mark and he thinks it's both a good thing and ready. For which I am very grateful. Mark has an expansive vision and solid knowledge of both the language and the people who use it, and so far, I think everything he's decided has been spot-on. I trust him to make the right decisions. He told me a couple of years ago that he wanted to rewrite the engine. I was appalled. I was afraid it would change too much. Was I ever wrong. He's making it better, and we won't lose anything. He's very good at guarding the syntax and backward compatibility. When we were going to replace our cement walk with flagstones, I asked someone how to tell if we'd found the right person to do the job. He said we had to find someone with an eye. Mark Waddingham has an eye. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Sockets on mobile…at last!
On 13/07/2013, at 10:19 AM, Roger Eller roger.e.el...@sealedair.com wrote: So the Android version will be next, right? Unfortunately not, if you remember mergSocket was crowd funded except we didn't make the funding target so in agreement with the funders (there were 5) I produced an iOS only external. On the up side android externals get closer every day. Cheers Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Sockets on mobile…at last!
It sounds more like mob-funding. We all know it only takes 3 to make a crowd. :-P On Jul 12, 2013 8:45 PM, Monte Goulding mo...@sweattechnologies.com wrote: On 13/07/2013, at 10:19 AM, Roger Eller roger.e.el...@sealedair.com wrote: So the Android version will be next, right? Unfortunately not, if you remember mergSocket was crowd funded except we didn't make the funding target so in agreement with the funders (there were 5) I produced an iOS only external. On the up side android externals get closer every day. Cheers Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
On 13/07/2013, at 10:37 AM, J. Landman Gay jac...@hyperactivesw.com wrote: For which I am very grateful. Mark has an expansive vision and solid knowledge of both the language and the people who use it, and so far, I think everything he's decided has been spot-on. I trust him to make the right decisions. I wasn't being critical of it I was just stating a fact. I think what he's doing is very important particularly given there's currently no documentation available other than a few dot points specifying the roadmap so if we are interested to do something we need to find out from him if that fits in the overall vision for the platform or not... -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Sockets on mobile…at last!
On 13/07/2013, at 10:56 AM, Roger Eller roger.e.el...@sealedair.com wrote: It sounds more like mob-funding. We all know it only takes 3 to make a crowd. :-P Well that ship sailed last year and didn't float... I see no reason why it would float now. -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Chained Behaviors
Great thread. I think I got this inspiration from Jacque. Chained behaviors allow one to create a well defined sub-message hierarchy distinct from the ordinary one. You can, in other words, write your own message path, encompassing specific aspects of your program that make sense for it. This seems profoundly important and enabling. And as Richard says, you only need to think about it if you need to think about it. The heart and soul of LC is not besmirched by functionality that is invisible if you decide to ignore it. A toolbox full of tools that you love and use all the time is no better than one that contains those tools as well as many others you never seem to need. The toolbox itself is larger, but I see no clutter. Craig ___ 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: Sockets on mobile…at last!
I searched for mergSocket on the list and found only the recent mentions. Maybe people didn't hear about it. And good work! Dar On Jul 12, 2013, at 6:45 PM, Monte Goulding wrote: On 13/07/2013, at 10:19 AM, Roger Eller roger.e.el...@sealedair.com wrote: So the Android version will be next, right? Unfortunately not, if you remember mergSocket was crowd funded except we didn't make the funding target so in agreement with the funders (there were 5) I produced an iOS only external. On the up side android externals get closer every day. Cheers Cheers -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Sockets on mobile…at last!
On 13/07/2013, at 11:04 AM, Dar Scott d...@swcp.com wrote: I searched for mergSocket on the list and found only the recent mentions. Maybe people didn't hear about it. There were posts about it... perhaps not mentioning mergSocket specifically... just mobile socket external. The Kickstarter campaign came along so I went quite about my little project so I didn't distract anyone. From here forward the simplest thing is to fix sockets in the engine. It's not a huge job which I've done some of but at the moment I'm lacking two things to get the job completed: time, motivation. Somebody else might have more of both... somebody might want to motivate me to find the time... but at the moment client work and android externals is top priority. -- Monte Goulding M E R Goulding - software development services mergExt - There's an external for that! ___ 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: Array glitch
Peter- Friday, July 12, 2013, 4:42:02 PM, you wrote: OK, all works fine for me too on a Mac so it does look like it's a Windows problem (maybe Linux too?) No problem here on linux (32-bit or 64-bit). -- -Mark Wieder mwie...@ahsoftware.net ___ 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: positioning stacks off screen in Linux
On 07/12/2013 07:32 PM, Mark Wieder wrote: Warren- Friday, July 12, 2013, 5:18:12 PM, you wrote: Trying this is Mint 9 in VirtualBox is even worse. Stacks cannot be moved completely out of view no matter what I try. Anyone else? Yep. Verified here on linux mint 14. Thanks, Mark. I've filed this as a bug. Warren ___ 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
