Re: Groups in the message path: Trapping Mouseup
User Guide: I tell myself periodically to read the whole thing (be never do…tinyDictionary has me hooked) … here it is, as you says, clearly stated on page 105 If background behavior is false, the group is in the message path for all controls it owns, but is not in the message path of any other object. If the background behavior is true, the group is also in the message path for any cards it is placed on. If you send a message to a card control, the message passes through the control, then the card, then any background groups on the card in order of number, then the stack. Since a group owns any controls that are part of the group, if you send a message to a control within a group, the group is in the message path for its own controls, regardless of whether it’s background behavior is true or false. If a group has already received a message because it was originally sent to one of the controls in the group, the message is not sent through the group again after the card has handled it. Tip: If you want a handler in a group's script to affect only the objects in the group, place the following statement at the beginning of the handler: if the owner of the target is not me then pass message. This filters out any objects that are not part of the group. I'm having fun there, but seriously, the User Guide has been pretty good in recent years. I'm often surprised at how the answers to many forum questions are covered well in it, yet when I ask about it most people don't even notice that it's there, the second-from-the-top item in LC's Help menu. ___ 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: Groups in the message path: Trapping Mouseup
On 12/10/19 9:20 PM, Richard Gaskin via use-livecode wrote: The Message Path discussion starts on p 101, with a pretty good diagram on p 102, including a distinction between Groups and Backgrounds. OMG - there's documentation? Admittedly I haven't looked at the User Guide in quite a while. That is indeed a fair diagram of the message path, although yours is more up-to-date by including behaviors. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
The PDF files are generated from .md files. The guides are split between two locations: https://github.com/livecode/livecode/tree/develop/docs/guides https://github.com/livecode/livecode-ide/tree/develop/Documentation/guides Thanks, Brian On Wed, Dec 11, 2019 at 12:21 AM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > > PS: I was going to include a link to the Github repo for anyone who > might want to help with errata or enhancements to the docs, but I > couldn't find the PDF sources in the /docs folder. What am I missing? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
Richard, I'm not sure you were posting this to the right forum. You see, this is the Livecode forum. We don't need no stinking User Guides! :-) Bob S > On Dec 10, 2019, at 21:20 , Richard Gaskin via use-livecode > wrote: > > Paul Dupuis wrote: > > Richard Gaskin, at one point, had a really excellent diagram of the > > LiveCode message hierarchy. If he sees this post and still has it > > perhaps he could post a link to it. > > Still there: > https://www.fourthworld.com/embassy/articles/revolution_message_path.html > > Since I made that back in the day (the file name hints at its age), I've > discovered a pretty great resource mysteriously unknown in our community, but > surprisingly comprehensive and includes a nearly identical diagram. > > It has more than 650 pages of comprehensive info on using LiveCode, broken > down into well organized sections and subsections, often with illustrations > and screen shots, all put together in a well-indexed PDF. > > They call it "LiveCode User Guide", and it's been secretly bundled with every > release of LiveCode for several years. :) > > I'm having fun there, but seriously, the User Guide has been pretty good in > recent years. I'm often surprised at how the answers to many forum questions > are covered well in it, yet when I ask about it most people don't even notice > that it's there, the second-from-the-top item in LC's Help menu. > > The Message Path discussion starts on p 101, with a pretty good diagram on p > 102, including a distinction between Groups and Backgrounds. > > In fact, p 105 includes a discussion of that distinction far more concise yet > no less helpful than my longish post here the other day. > > > PS: I was going to include a link to the Github repo for anyone who might > want to help with errata or enhancements to the docs, but I couldn't find the > PDF sources in the /docs folder. What am I missing? > > -- > Richard Gaskin ___ 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: Groups in the message path: Trapping Mouseup
Paul Dupuis wrote: > Richard Gaskin, at one point, had a really excellent diagram of the > LiveCode message hierarchy. If he sees this post and still has it > perhaps he could post a link to it. Still there: https://www.fourthworld.com/embassy/articles/revolution_message_path.html Since I made that back in the day (the file name hints at its age), I've discovered a pretty great resource mysteriously unknown in our community, but surprisingly comprehensive and includes a nearly identical diagram. It has more than 650 pages of comprehensive info on using LiveCode, broken down into well organized sections and subsections, often with illustrations and screen shots, all put together in a well-indexed PDF. They call it "LiveCode User Guide", and it's been secretly bundled with every release of LiveCode for several years. :) I'm having fun there, but seriously, the User Guide has been pretty good in recent years. I'm often surprised at how the answers to many forum questions are covered well in it, yet when I ask about it most people don't even notice that it's there, the second-from-the-top item in LC's Help menu. The Message Path discussion starts on p 101, with a pretty good diagram on p 102, including a distinction between Groups and Backgrounds. In fact, p 105 includes a discussion of that distinction far more concise yet no less helpful than my longish post here the other day. PS: I was going to include a link to the Github repo for anyone who might want to help with errata or enhancements to the docs, but I couldn't find the PDF sources in the /docs folder. What am I missing? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
Just for reference, Dar Scott wrote a Primer in Message Mechanics: http://pages.swcp.com/dsc/revstacks.html Al on Tue, 10 Dec 2019, Paul Dupuis wrote: [snip] Richard Gaskin, at one point, had a really excellent diagram of the LiveCode message hierarchy. If he sees this post and still has it perhaps he could post a link to 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: Groups in the message path: Trapping Mouseup
Mark Waddington gave the answer if need. I really want "shared groups" and not "backgroundGroups" Then the scripts are encapsulated. I turned off backgroundBehavior on all groups. A click on top layer button (no script) now registers in the stack script with its target. I tried it, Yay! After 25 years, still learning…. So if I have a button X with a mouseDown handler in a Group Y also with a mouseDown handler and in my card script (or stack script) also have a mouseDown handler ___ 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: Groups in the message path: Trapping Mouseup
On 12/10/19 11:39 AM, Sannyasin Brahmanathaswami via use-livecode wrote: So then to trap "the target" in the stack script, require putting pass mousedown (or mouseWhatever) in all the background groups (all of which contain their our MouseDown) Correct? Only if you want to handle the mouseUp message *first* in the background group script and *then* in the stack script. remember the use case: we do not want and script in *any* button or top object that receives a click or touch. The card becomes a pure "view" object. Q: Why do you have a background group? And mouseUp handlers in it? This will catch any mouseUp messages that aren't already captured by controls on the card, and in addition will catch mouseUp messages if you click on the card itself. Why not just have the mouseUp handler in the stack script? Or put the buttons into their own (not background) group and have the mouseUp handler there? Or have a behavior script for the buttons or group that handles the mouseUp messages? -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
So if I have a button X with a mouseDown handler in a Group Y also with a mouseDown handler and in my card script (or stack script) also have a mouseDown handler If I click on button X and I only want button X to handle the mouseDown, I do not 'pass mouseDown' in the button X mouseDown handler If I click on button X and I also want another mouseDown handler in the message path - in addition to the one in button X - to do something in response, then I need to 'pass mouseDown' in the button script. In this example, a pass mouseDown in the button mouseDown handler passes the message to the group that contains the button. If that group's mouseDown handler also does a pass mouseDown, then the card or stack gets the mouseDown as well. If they do not pass the message its stops there. Richard Gaskin, at one point, had a really excellent diagram of the LiveCode message hierarchy. If he sees this post and still has it perhaps he could post a link to it. On 12/10/2019 2:39 PM, Sannyasin Brahmanathaswami via use-livecode wrote: So then to trap "the target" in the stack script, require putting pass mousedown (or mouseWhatever) in all the background groups (all of which contain their our MouseDown) Correct? remember the use case: we do not want and script in *any* button or top object that receives a click or touch. The card becomes a pure "view" object. @paul If you have groups where you need to pass a mouseDown (or mosueWhatever) mesage to the card or stack, just add a behavior to the group for a script that contain handlers like on mouseDown pass mouseDown end mouseDown on mouseUp pass mouseUp end mouseUp Although if there is no handler for the mouse event it should pass to the card and then the stack and then any library or backscripts and then the engine. ___ 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: Groups in the message path: Trapping Mouseup
@ Mark Waddington That's it! Thank you! If you turn 'background behavior' off, then your shared group should no longer receive messages after the card does. ___ 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: Groups in the message path: Trapping Mouseup
So then to trap "the target" in the stack script, require putting pass mousedown (or mouseWhatever) in all the background groups (all of which contain their our MouseDown) Correct? remember the use case: we do not want and script in *any* button or top object that receives a click or touch. The card becomes a pure "view" object. @paul If you have groups where you need to pass a mouseDown (or mosueWhatever) mesage to the card or stack, just add a behavior to the group for a script that contain handlers like on mouseDown pass mouseDown end mouseDown on mouseUp pass mouseUp end mouseUp Although if there is no handler for the mouse event it should pass to the card and then the stack and then any library or backscripts and then the engine. ___ 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: Groups in the message path: Trapping Mouseup
Mark Wieder wrote: > The syntax for describing the message path gets > pretty gnarly. It gets somewhat simpler when we consider the origins of the object model, though admittedly this is help more for us ol' timers than newcomers. For newcomers I just don't mention backgrounds at all unless there's a specific need for it, and as long as I do that the message path is pretty easily learned, HISTORY --- HC didn't have groups, and its background was a layer that filled the entire card. For what it was, its message path was reasonable straightforward once you learned what the background layer is and how to use it. MC had groups, far more flexible than backgrounds, and their place in the message path is consistent with everything else: starting at the control, moving on to containers the control is within. MC's groups were super-awesome for many of us HC fans who'd dreamed of such a feature for years, BUT - The MC object model had no background layer, so importing HC stacks would be a non-starter. So Dr. Raney adapted the group object so that it could also serve the role of an HC background. Once a group is made sharable, it acts like an HC group. Sounds good, but - It's counter to the rest of the MC object model's message path. So, after MC became LC, Mark Waddingham explored ways to both retain the compatibility with HC while respecting that LC is inherently a different model, and split the way shared groups are handled into two properties: sharedBehavior: allows a group to be automatically copied to new cards, retaining the simplicity of the object model in the message path, in which messages flow from the control through its containers in visual order (group then card then stack). backgroundBehavior: emulates HC by altering the position of the object in the message path per HC's convention for backgrounds (card then background then stack). CURRENT USAGE - As long as we think of backgroundBehavior as a sort of HC compatibility mechanism, distinguishing its affect on the message path becomes easier. For newcomers, I don't even mention backgroundBehavior at all, introducing them only to sharedBehavior. With this orientation I find they enjoy the benefits of shared groups and they never get confused. -- Richard Gaskin Fourth World Systems ___ 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: Groups in the message path: Trapping Mouseup
On 12/9/19 11:13 AM, Alex Tweedly via use-livecode wrote: I think the correct (and nit-picky) statement is ... Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior **for the background group**." **and also a behavior script for the object being clicked on** Hope I'm not misconstruing it, and that's not making everything more confusing ... Thanks for clarifying. The syntax for describing the message path gets pretty gnarly. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
On 12/9/19 6:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote: In this use case, - the button "starWidget" is a "standalone" button on an independent layer on the card and not a part of any group -- @Jacque... the groups that are trapping the mouseup I are background groups using on various card. Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior." BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would mean BR - are you maybe reading more into it than Mark meant. I think the correct (and nit-picky) statement is ... Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior **for the background group**." Hope I'm not misconstruing it, and that's not making everything more confusing ... Alex. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
On 2019-12-09 14:30, Sannyasin Brahmanathaswami via use-livecode wrote: -- background groups: "encapsulated" only receive mouse/touch events from objects that are contain in "itself" -- group -- behaviors: "encapsulated": only receive mouse events for the object or group the behavior is assigned to. Isn't this a bug? Otherwise, "We have chaos on the Highway 666, total car wreck on the Message Path" No - background groups have always worked this way (and behaviors work the way you'd expect, they receive events which the object they are attached to doesn't handle). All background groups placed on a card appear after the card in the message path. There are two settings you can apply to a group - 'Shared Group' and 'Background behavior'. The 'Shared Group' setting means it can be placed on more than one card. The 'Background Behavior' setting means it behaves like a background - rather than a normal group. If you turn 'background behavior' off, then your shared group should no longer receive messages after the card does. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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: Groups in the message path: Trapping Mouseup
On 12/9/19 6:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote: In this use case, - the button "starWidget" is a "standalone" button on an independent layer on the card and not a part of any group -- @Jacque... the groups that are trapping the mouseup I are background groups using on various card. Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior." BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would mean If you set a group to have background behavior then it sits above the stack layer in the message path (or below, depending on how you view the layers). At any rate, messages will hit the background group before the stack script sees them. That's the way it is, the way it has always been, and the way the path was designed from the start. If you want something different you need to rethink your stack design. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
I use groups in use cases where I want a on mouseDown script in the group to respond to any mouse click anywhere in the rect of the group, so, no, groups should not ONLY respond to mouse messages passed though object contained in the group If you have groups where you need to pass a mouseDown (or mosueWhatever) mesage to the card or stack, just add a behavior to the group for a script that contain handlers like on mouseDown pass mouseDown end mouseDown on mouseUp pass mouseUp end mouseUp Although if there is no handler for the mouse event it should pass to the card and then the stack and then any library or backscripts and then the engine. On 12/9/2019 9:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote: In this use case, - the button "starWidget" is a "standalone" button on an independent layer on the card and not a part of any group -- @Jacque... the groups that are trapping the mouseup I are background groups using on various card. Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior." BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would mean -- background groups: "encapsulated" only receive mouse/touch events from objects that are contain in "itself" -- group -- behaviors: "encapsulated": only receive mouse events for the object or group the behavior is assigned to. Isn't this a bug? Otherwise, "We have chaos on the Highway 666, total car wreck on the Message Path" ___ 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: Groups in the message path: Trapping Mouseup
In this use case, - the button "starWidget" is a "standalone" button on an independent layer on the card and not a part of any group -- @Jacque... the groups that are trapping the mouseup I are background groups using on various card. Mark Weider says "A background group will definitely get the message before the stack script does. Also any script being used as a behavior." BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would mean -- background groups: "encapsulated" only receive mouse/touch events from objects that are contain in "itself" -- group -- behaviors: "encapsulated": only receive mouse events for the object or group the behavior is assigned to. Isn't this a bug? Otherwise, "We have chaos on the Highway 666, total car wreck on the Message Path" ___ 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: Groups in the message path: Trapping Mouseup
On 12/8/19 4:04 PM, J. Landman Gay via use-livecode wrote: I take that back, the card group shouldn't get the message. Sounds like something else is wrong. A background group will definitely get the message before the stack script does. Also any script being used as a behavior. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Groups in the message path: Trapping Mouseup
I take that back, the card group shouldn't get the message. Sounds like something else is wrong. On 12/8/19 5:24 PM, J. Landman Gay via use-livecode wrote: Is the group that receives the mouseUp a card group or a background group? If I remember right, messages go from the button, to all card groups, then to the card, then all background groups, then to the stack. So if it's a card group, it will get the message before the stack does. On 12/8/19 1:55 PM, Sannyasin Brahmanathaswami via use-livecode wrote: I think this a old problem that is re-surfacing. Or else it is known…. 9.6 dp1, in the message path different independent groups are not encapsulated. button "starWidget" -- has no script -- is not a part of any group Stack script: on mouseup put the short name of the target put the short name of the target into tTarget switch tTarget case(s) # various button names # consolidate all UI actions that not part of a group # to the stack script end switch end mouseup # the card are several groups, # each with its own mouse handlers # I click on button "starWidget" -- nothing happens…hmm, no errors either… # start profiling scripts (new trick I found) # click on button "starWidget" # stop profiling scripts: # Voila! the mouseup was trapped by one the other groups, as if they were in the message path. Is there any way around this? Meanwhile I have to plug into every button explicit handlers. Tedious, make debugging painful… BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- 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: Groups in the message path: Trapping Mouseup
Is the group that receives the mouseUp a card group or a background group? If I remember right, messages go from the button, to all card groups, then to the card, then all background groups, then to the stack. So if it's a card group, it will get the message before the stack does. On 12/8/19 1:55 PM, Sannyasin Brahmanathaswami via use-livecode wrote: I think this a old problem that is re-surfacing. Or else it is known…. 9.6 dp1, in the message path different independent groups are not encapsulated. button "starWidget" -- has no script -- is not a part of any group Stack script: on mouseup put the short name of the target put the short name of the target into tTarget switch tTarget case(s) # various button names # consolidate all UI actions that not part of a group # to the stack script end switch end mouseup # the card are several groups, # each with its own mouse handlers # I click on button "starWidget" -- nothing happens…hmm, no errors either… # start profiling scripts (new trick I found) # click on button "starWidget" # stop profiling scripts: # Voila! the mouseup was trapped by one the other groups, as if they were in the message path. Is there any way around this? Meanwhile I have to plug into every button explicit handlers. Tedious, make debugging painful… BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- 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: Groups in the message path: Trapping Mouseup
Hi. It is hard for me to understand without more info about the case statements. But when you have this: # I click on button "starWidget" -- nothing happens…hmm, no errors either… Do you really mean nothing, not even that the: put the short name of the target does not fire? Craig -Original Message- From: Sannyasin Brahmanathaswami via use-livecode To: How LiveCode Cc: Sannyasin Brahmanathaswami Sent: Sun, Dec 8, 2019 2:56 pm Subject: Groups in the message path: Trapping Mouseup I think this a old problem that is re-surfacing. Or else it is known…. 9.6 dp1, in the message path different independent groups are not encapsulated. button "starWidget" -- has no script -- is not a part of any group Stack script: on mouseup put the short name of the target put the short name of the target into tTarget switch tTarget case(s) # various button names # consolidate all UI actions that not part of a group # to the stack script end switch end mouseup # the card are several groups, # each with its own mouse handlers # I click on button "starWidget" -- nothing happens…hmm, no errors either… # start profiling scripts (new trick I found) # click on button "starWidget" # stop profiling scripts: # Voila! the mouseup was trapped by one the other groups, as if they were in the message path. Is there any way around this? Meanwhile I have to plug into every button explicit handlers. Tedious, make debugging painful… BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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
