Groups in the message path: Trapping Mouseup

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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 <[hidden email]>
To: How LiveCode <[hidden email]>
Cc: Sannyasin Brahmanathaswami <[hidden email]>
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
@ 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Groups in the message path: Trapping Mouseup

Bob Sneidar via use-livecode
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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12