Re: Image Cropping Tool for Livecode
Jacque wrote: On 12/4/11 8:09 PM, Sivakatirswami wrote: As anyone created a image cropping tool for LiveCode? If you hold down the command key while resizing an image, it gets cropped to the new size. There's no warning, it just happens. That's a frightening way to have users accidentally lose data. Is there a property to turn that off, or can we trap for commandKeyDown on mouseDown to override it? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: Image Cropping Tool for Livecode
Hi Richard, I never accidentally lost my data that way. Did you? -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Become our partner in sales http://qery.us/1bq Start selling Color Converter today. 20% commission! On 5 dec 2011, at 14:51, Richard Gaskin wrote: That's a frightening way to have users accidentally lose data. Is there a property to turn that off, or can we trap for commandKeyDown on mouseDown to override it? ___ 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: Image Cropping Tool for Livecode
Mark Schonewille wrote: On 5 dec 2011, at 14:51, Richard Gaskin wrote: That's a frightening way to have users accidentally lose data. Is there a property to turn that off, or can we trap for commandKeyDown on mouseDown to override it? Hi Richard, I never accidentally lost my data that way. Did you? LOL. I haven't had such reports yet, but when delivering robust systems we don't ship things with the potential for losing data in the hope that the user simply won't perform the action that would cause such loss, but aim a little higher to prevent the potential for loss altogether. So the question seems relevant: how can we turn off this behavior? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: Image Cropping Tool for Livecode
uhm... don't enable the pointer tool? set the resizability to false? set the editable to false? Seriously, if you have a image editing app, then you might want to use a cached version of the image anyway, because of rotation and similar ways to lose image quality. This is such a non issue for 99% of the apps, and easy to solve for everyone else, i'm amazed that you even feel the need to ask this question like that. On 5 Dec 2011, at 15:55, Richard Gaskin wrote: Mark Schonewille wrote: On 5 dec 2011, at 14:51, Richard Gaskin wrote: That's a frightening way to have users accidentally lose data. Is there a property to turn that off, or can we trap for commandKeyDown on mouseDown to override it? Hi Richard, I never accidentally lost my data that way. Did you? LOL. I haven't had such reports yet, but when delivering robust systems we don't ship things with the potential for losing data in the hope that the user simply won't perform the action that would cause such loss, but aim a little higher to prevent the potential for loss altogether. So the question seems relevant: how can we turn off this behavior? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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 -- Watch live presentations every Saturday: http://livecode.tv Use an alternative Dictionary viewer: http://bjoernke.com/bvgdocu/ Chat with other RunRev developers: http://bjoernke.com/chatrev/ ___ 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: Image Cropping Tool for Livecode
Richard, I see no reason to turn this feature off. I never give the users of my software access to the pointer tool, which means that can never lose data this way. Personally, I really appreciate this feature because it is a very easy way to crop images: no need to edit them in an external editor. As long as LiveCode users don't report this as an actual problem, I'd say don't fix it if it works. I'd rather not request a new feature to optionally turn off image cropping. I'd rather wish RunRev to invest the money I pay for licenses on something really useful, such as truly native text objects. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Become our partner in sales http://qery.us/1bq Start selling Color Converter today. 20% commission! On 5 dec 2011, at 15:55, Richard Gaskin wrote: LOL. I haven't had such reports yet, but when delivering robust systems we don't ship things with the potential for losing data in the hope that the user simply won't perform the action that would cause such loss, but aim a little higher to prevent the potential for loss altogether. So the question seems relevant: how can we turn off this behavior? ___ 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: Image Cropping Tool for Livecode
Mark Schonewille wrote: On 5 dec 2011, at 15:55, Richard Gaskin wrote: LOL. I haven't had such reports yet, but when delivering robust systems we don't ship things with the potential for losing data in the hope that the user simply won't perform the action that would cause such loss, but aim a little higher to prevent the potential for loss altogether. So the question seems relevant: how can we turn off this behavior? I see no reason to turn this feature off. I never give the users of my software access to the pointer tool, which means that can never lose data this way. That seems to be the common workaround to dodgy pointer tool behaviors. Jan and Ken take that approach as well, writing hundreds of lines of code to emulate the pointer tool because the pointer tool itself just isn't as useful as SuperCard's implementation. As long as LiveCode users don't report this as an actual problem, I'd say don't fix it if it works. I'd rather not request a new feature to optionally turn off image cropping. I'd rather wish RunRev to invest the money I pay for licenses on something really useful, such as truly native text objects. Agreed. Please note that I didn't make a feature request, just wondering if one can trap existing messages/properties to prevent this undocumented behavior. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: Image Cropping Tool for Livecode
Richard, You can set the cantSelect of objects to true. That should solve it in most cases, unless... you have a picture that needs to be selectable :-) -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Become our partner in sales http://qery.us/1bq Start selling Color Converter today. 20% commission! On 5 dec 2011, at 16:53, Richard Gaskin wrote: snip Agreed. Please note that I didn't make a feature request, just wondering if one can trap existing messages/properties to prevent this undocumented behavior. ___ 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: Image Cropping Tool for Livecode
On 12/5/11 7:51 AM, Richard Gaskin wrote: Jacque wrote: On 12/4/11 8:09 PM, Sivakatirswami wrote: As anyone created a image cropping tool for LiveCode? If you hold down the command key while resizing an image, it gets cropped to the new size. There's no warning, it just happens. That's a frightening way to have users accidentally lose data. Is there a property to turn that off, or can we trap for commandKeyDown on mouseDown to override it? It's in the engine, it isn't a property, but it's been there for three or four years and I think if it were an issue we'd have heard by now. It's largely a developer thing, and very convenient. As others said, if your app doesn't use the pointer tool then it's a non-issue. I suppose you could trap mousemove and check if the command key is down and tool is the pointer tool to avoid the problem. -- 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: Image Cropping Tool for Livecode
Mark Schonewille wrote: On 5 dec 2011, at 16:53, Richard Gaskin wrote: Agreed. Please note that I didn't make a feature request, just wondering if one can trap existing messages/properties to prevent this undocumented behavior. You can set the cantSelect of objects to true. That should solve it in most cases, unless... you have a picture that needs to be selectable :-) Indeed, there's the rub. ;) There are sometimes unexpected-but-fully-understandable side-effects with using the cantSelect property, but very useful for certain things like using a graphic at the back of a drawing group to catch drag-and-drop messages. Someday I'll get around to finishing my port of SuperCard's SampleDraw example app in LC to illustrate this sort of thing. While I occasionally complain about some of the nuances with the differences between SC and LC pointer tool behaviors, in all fairness I have to admit that having groups with the option of turning off their selectGroupedControls, coupled with having a scrolling group that can occupy only part of a window rather than require the whole window, makes some aspects of creating custom drawing environments in LC much more powerful than anything I've used before. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: Image Cropping Tool for Livecode
Jacque - I suppose you could trap mousemove and check if the command key is down and tool is the pointer tool to avoid the problem. Good suggestion. Thanks. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: [OT}] Hypercard and an uneasy read.
I think the reason is because he wanted to be able to reverse the decision, if at any point Apple wanted to resurrect the product in the future. Most software companies that go under do not open source their stuff, if for no other reason than to say to the public who didn't want to pay for it, Okay then, NOBODY WINS!!! Bob On Dec 2, 2011, at 11:16 PM, Peter Alcibiades wrote: Yes, Jobs killed a lot of things that were losing money - but that does not explain why Apple would not open-source Hypercard if it didn't want to support it. It was possible to stop the losses without killing the product, but he chose not to. There had to be a reason 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: Image Cropping Tool for Livecode
I think the issue isn't really whether or not someone will accidently use a feature, but more along the lines of having the engine assume behaviors we don't know of, or can't override in some way or another. My friend and fellow LC'er, Jerry Daniels, is now working in RB. He needs to as it has an embedded browser object which 'just works.' Discussions with him over the experience is most interesting. RB forces certain ways of working-- and doesn't 'allow' one to roll their own controls without significant outside development-- something which LC has been able to do for years. I appreciate the basic nature of the engine and don't have a problem building tools to allow one to crop or resize images rather than have it embedded. As Jan and Ken do, I typically write my own using browse mode-- a bit more difficult, but there you have complete control. Sivakatirswami, I'll take a peek and see what crop code I may have lying around. Most of it is embedded in much larger image editing types of handlers. ___ 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: setProp and Lock messages
Hi Richard, You're right the reference manual does say that. And on the very next page, it says: If you use the set command within a setprop handler to set the custom property for the current object, no setProp trigger is sent to the target object. (This is to avoid runaway recursion, where the setprop handler triggers itself). Your example and mine appear to contradict each other so I guess there must be two different circumstances described by these two references. On Sun, Dec 4, 2011 at 12:10 PM, Richard Gaskin ambassa...@fourthworld.comwrote: Pete wrote: I think the reference to the documentation not being believable alluded to the LC documentation not the datagrid documentation. The LC Reference Manual and the dictionary are old and definitely contain inaccuracies. On the topic of setprop and recursion, for example, the reference manual clearly states that you don't need to user lock messages to prevent recursion but, as several people have mentioned in this thread, you do. Here's what the docs say with regard to recursion for setProp: Caution! If a setProp handler in one object's script sets the custom property for a different object, and the first object is in the second object's message path, a runaway recursion will result. For example, if the following handler is in a card script, and you set the myCustomProperty of a button on the card, runaway recursion will result: setProp myCustomProperty newValue set the myCustomProperty of the target to newValue + 1 -- Because the target is the button, and this handler is in -- the card, the above statement sends another setProp trigger -- to the button. end myCustomProperty To avoid this problem, set the lockMessages property to true before setting the custom property. I believe that's correct, and have not experienced any bugs which differ from that description. Has anyone here found a recipe for a behavior which contradicts that description? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv __**_ 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 -- Pete Molly's Revenge http://www.mollysrevenge.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: setProp and Lock messages
Pete wrote: On Sun, Dec 4, 2011 at 12:10 PM, Richard Gaskin wrote: Here's what the docs say with regard to recursion for setProp: Caution! If a setProp handler in one object's script sets the custom property for a different object, and the first object is in the second object's message path, a runaway recursion will result. For example, if the following handler is in a card script, and you set the myCustomProperty of a button on the card, runaway recursion will result: setProp myCustomProperty newValue set the myCustomProperty of the target to newValue + 1 -- Because the target is the button, and this handler is in -- the card, the above statement sends another setProp trigger -- to the button. end myCustomProperty To avoid this problem, set the lockMessages property to true before setting the custom property. ... Hi Richard, You're right the reference manual does say that. And on the very next page, it says: If you use the set command within a setprop handler to set the custom property for the current object, no setProp trigger is sent to the target object. (This is to avoid runaway recursion, where the setprop handler triggers itself). Your example and mine appear to contradict each other so I guess there must be two different circumstances described by these two references. In my pre-coffee state it seems we're looking at the same thing, with one small but important distinction: Recursion will not occur if the setProp handler for a given property label sets the value of a property using that label, BUT if it calls any other handler which sets that property then recursion will occur. Did I miss something? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ 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: [OT}] Hypercard and an uneasy read.
I had a little company that went bust due to lack of funds. When that happens, the assets of the business must be sold off to pay the creditors (we owed national insurance, PAYE tax, hosting services, salaries, etc). In hopes of trying to raise cash to pay off those debts, the solicitor would *never* give something away when they could sell it. I suppose I could have offered them a pittance for the software and then open sourced it, but as I hadn't drawn a salary in 2 years, that was difficult...and I'm not sure why I would have done it anyway, as it needed specialist knowledge to run the software. I'm sure there could be elements of I'm going home and taking my ball with me, but in our case it came down to cash. That said, I doubt that's why Jobs didn't open source it. I would suspect that for him and his team it's always been about making the design of everything special...so special, you must be an alcolyte to play. (Apple can charge alcolytes, because they'll go to enough trouble). Average humans won't go to the trouble to create software for a closed system, so Apple guarantees it's 30%. -Ken On 05/12/2011 17:17, Bob Sneidar wrote: I think the reason is because he wanted to be able to reverse the decision, if at any point Apple wanted to resurrect the product in the future. Most software companies that go under do not open source their stuff, if for no other reason than to say to the public who didn't want to pay for it, Okay then, NOBODY WINS!!! ___ 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: setProp and Lock messages
No I don't think you're missing anything - I am :-) I'm sure what you said is correct although I haven't tried it. The example in the manual regarding the use of lockMessages seems to relate to a setProp handler at the stack level to handle a custom property used by all cards in the stack. My poor brain can't discern why that would result in recursion since the example specifically sets the custom property of the target which presumably would be the card from which the set command originated. Anyway, I agree we're pretty much talking about the same thing but we kinda got off the topic of documentation discrepancies. Turns out my assertion that the use of lock messages in a setProp handler isn't a documentation error - I just happened to read one of the reference manual notes about it instead of all of them, my bad. I'm still trying to figure out what to do regarding the use of setProp handlers and the likelihood of lock messages being true when they are called. In a self contained application it's just a case of careful coding habits but in the case of a library of handlers provided for the use of other developers, there is no control over what another developer might do in their own code before calling a handler in the library that issues a setProp command, other than make it very clear that setting lock messages to true might produce unexpected results. I'm leaning towards abandoning setProp/GetProp in favour of the localised handler approach(which I use elsewhere in my library for other purposes. The dictionary entry for lock messages doesn't exactly inspire confidence either: Sets the lockMessages property to true, preventing setProp triggers, getProp calls, and certain messages from being sent. Which certain messages? On Mon, Dec 5, 2011 at 9:39 AM, Richard Gaskin ambassa...@fourthworld.comwrote: In my pre-coffee state it seems we're looking at the same thing, with one small but important distinction: Recursion will not occur if the setProp handler for a given property label sets the value of a property using that label, BUT if it calls any other handler which sets that property then recursion will occur. Did I miss something? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv __**_ 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 -- Pete Molly's Revenge http://www.mollysrevenge.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: Image Cropping Tool for Livecode
Hi All, Reading about masking and cropping images, How both actions differs from importing an snapshot of an area? Thanks in advance! Al -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Image-Cropping-Tool-for-Livecode-tp4158971p4161689.html Sent from the Revolution - User mailing list archive at Nabble.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
