before vs on in behavior scripts

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

before vs on in behavior scripts

Devin Asay
All,

If a button has a behavior attached to it, and the behavior script has a 'before mouseUp' handler, can the behavior script also have a 'on mouseUp' handler?

I could swear the answer was yes; I thought I had done that before, but now when I try it, it doesn't work. (In LC 6.5.x. and 6.6.0RC2). Instead I have to put the 'in mouseUp' in the button's script.

Of course I might be completely missing the point of 'before' and 'after' handlers. Wouldn't be the first time.

Regards,

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

_______________________________________________
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: before vs on in behavior scripts

ScottR
How are you determining that "on" isn't working?  Is it possible that "on"
is executing immediately after "before"?

Placing the following in a behavior script works fine here:

before mouseUp
   answer "A"
end mouseUp

on mouseUp
   answer "B"
end mouseUp


If you need some kind of alternate behavior to take place after "before"
that isn't "on", you might consider "after".  I know, it's a lot of
prepositions ...

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 3/18/14 4:33 PM, "Devin Asay" <[hidden email]> wrote:

>All,
>
>If a button has a behavior attached to it, and the behavior script has a
>'before mouseUp' handler, can the behavior script also have a 'on
>mouseUp' handler?
>
>I could swear the answer was yes; I thought I had done that before, but
>now when I try it, it doesn't work. (In LC 6.5.x. and 6.6.0RC2). Instead
>I have to put the 'in mouseUp' in the button's script.
>
>Of course I might be completely missing the point of 'before' and 'after'
>handlers. Wouldn't be the first time.
>
>Regards,
>
>Devin
>
>
>Devin Asay
>Office of Digital Humanities
>Brigham Young University
>
>_______________________________________________
>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: before vs on in behavior scripts

ScottR
I didn't realize it until just now, but this is the order of events:

before mouseUp
   answer "A"
end mouseUp

on mouseUp
   answer "B"
end mouseUp

after mouseUp
   answer "C"
end mouseUp


Really cool stuff for custom behaviors, but I'm still trying to come up
with a nifty use for the "after" event.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 3/18/14 7:44 PM, "Scott Rossi" <[hidden email]> wrote:

>How are you determining that "on" isn't working?  Is it possible that "on"
>is executing immediately after "before"?
>
>Placing the following in a behavior script works fine here:
>
>before mouseUp
>   answer "A"
>end mouseUp
>
>on mouseUp
>   answer "B"
>end mouseUp
>
>
>If you need some kind of alternate behavior to take place after "before"
>that isn't "on", you might consider "after".  I know, it's a lot of
>prepositions ...
>
>Regards,
>
>Scott Rossi
>Creative Director
>Tactile Media, UX/UI Design
>
>
>
>
>On 3/18/14 4:33 PM, "Devin Asay" <[hidden email]> wrote:
>
>>All,
>>
>>If a button has a behavior attached to it, and the behavior script has a
>>'before mouseUp' handler, can the behavior script also have a 'on
>>mouseUp' handler?
>>
>>I could swear the answer was yes; I thought I had done that before, but
>>now when I try it, it doesn't work. (In LC 6.5.x. and 6.6.0RC2). Instead
>>I have to put the 'in mouseUp' in the button's script.
>>
>>Of course I might be completely missing the point of 'before' and 'after'
>>handlers. Wouldn't be the first time.
>>
>>Regards,
>>
>>Devin
>>
>>
>>Devin Asay
>>Office of Digital Humanities
>>Brigham Young University
>>
>>_______________________________________________
>>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
>



_______________________________________________
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: before vs on in behavior scripts

Devin Asay

> On Mar 18, 2014, at 8:54 PM, "Scott Rossi" <[hidden email]> wrote:
>
> I didn't realize it until just now, but this is the order of events:
>
> before mouseUp
>   answer "A"
> end mouseUp
>
> on mouseUp
>   answer "B"
> end mouseUp
>
> after mouseUp
>   answer "C"
> end mouseUp

That's what I thought. But when I tried it earlier today it didn't work with both and after end and on handler. I'll go back and check to make sure I don't have another mouse up Hendler somewhere in the message path.

Devin
_______________________________________________
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: before vs on in behavior scripts

J. Landman Gay
On 3/19/14, 12:14 AM, Devin Asay wrote:
> it didn't work with both and after end and on handler

Lay off the Scotch, Devin. ;) Though actually, if you read it out loud,
it makes sense.

 > I don't have another mouse up Hendler

Reminds me of something I saw: "Frankly, auto-correct, I'm tired of your
shirt."

--
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: before vs on in behavior scripts

Bob Sneidar-2
Actually, you need to down a few, and then all of this makes sense.

Bob


On Mar 18, 2014, at 22:26 , J. Landman Gay <[hidden email]> wrote:

> On 3/19/14, 12:14 AM, Devin Asay wrote:
>> it didn't work with both and after end and on handler
>
> Lay off the Scotch, Devin. ;) Though actually, if you read it out loud, it makes sense.
>
> > I don't have another mouse up Hendler
>
> Reminds me of something I saw: "Frankly, auto-correct, I'm tired of your shirt."
>
> --
> 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


_______________________________________________
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: before vs on in behavior scripts

Devin Asay
In reply to this post by J. Landman Gay

On Mar 18, 2014, at 11:26 PM, "J. Landman Gay" <[hidden email]>
 wrote:

> On 3/19/14, 12:14 AM, Devin Asay wrote:
>> it didn't work with both and after end and on handler
>
> Lay off the Scotch, Devin. ;) Though actually, if you read it out loud, it makes sense.
>
> > I don't have another mouse up Hendler
>
> Reminds me of something I saw: "Frankly, auto-correct, I'm tired of your shirt."

Hey, I resemble that remark. I typed the whole thing with my own fink hairs!

(Stop that, Siri!)

Devin

Devin Asay
Office of Digital Humanities
Brigham Young University


_______________________________________________
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: before vs on in behavior scripts

mwieder
In reply to this post by J. Landman Gay
J. Landman Gay <jacque@...> writes:

>
> On 3/19/14, 12:14 AM, Devin Asay wrote:
> > it didn't work with both and after end and on handler
>
> Lay off the Scotch, Devin. ;) Though actually, if you read it out loud,
> it makes sense.

This me had to read "with both and after end and on" aloud three times
before it started making sense.

--
 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
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: before vs on in behavior scripts

Jan Schenkel
In reply to this post by ScottR
Hi Scott et al,

The 'after' handler in the behavior script will be executed even if the control script itself contains an 'on' handler which forgets to 'pass' the message. This is really useful for custom controls where you want to allow the developer to implement standard message handlers but ensure the control instance returns to a normal state.

Let's say you have your own implementation of a button control.
Your behavior script would handle 'before mouseDown' to turn on the hilited appearance, and handle 'after mouseUp' and 'after mouseRelease' to turn off the hilited appearance. Now the developer can simple handle 'on mouseUp' to execute his business logic, and doesn't have to remember to include a 'pass mouseUp' to ensure the appearance is restored.

At first I was skeptical about behaviors, as I could do everything I needed using frontscripts and backscripts. Its convenience was in having all code in one place, but there were still waysd for the custom control user to mess things up (by not passing messages). So thanks to the addition of 'before' and 'after' message handlers and chained behaviors, this feature has really matured and everyone should use it :)

Jan Schenkel.
=====
Quartam Reports & PDF Library for LiveCode
www.quartam.com

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

--------------------------------------------
On Tue, 3/18/14, Scott Rossi <[hidden email]> wrote:

 Subject: Re: before vs on in behavior scripts
 To: "LiveCode Mail List" <[hidden email]>
 Date: Tuesday, March 18, 2014, 7:54 PM
 
 I didn't realize it until just now,
 but this is the order of events:
 
 before mouseUp
    answer "A"
 end mouseUp
 
 on mouseUp
    answer "B"
 end mouseUp
 
 after mouseUp
    answer "C"
 end mouseUp
 
 
 Really cool stuff for custom behaviors, but I'm still trying
 to come up
 with a nifty use for the "after" event.
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
 
 
 
 On 3/18/14 7:44 PM, "Scott Rossi" <[hidden email]>
 wrote:
 
 >How are you determining that "on" isn't working? 
 Is it possible that "on"
 >is executing immediately after "before"?
 >
 >Placing the following in a behavior script works fine
 here:
 >
 >before mouseUp
 >   answer "A"
 >end mouseUp
 >
 >on mouseUp
 >   answer "B"
 >end mouseUp
 >
 >
 >If you need some kind of alternate behavior to take
 place after "before"
 >that isn't "on", you might consider "after".  I
 know, it's a lot of
 >prepositions ...
 >
 >Regards,
 >
 >Scott Rossi
 >Creative Director
 >Tactile Media, UX/UI Design
 >
 >
 >
 >
 >On 3/18/14 4:33 PM, "Devin Asay" <[hidden email]>
 wrote:
 >
 >>All,
 >>
 >>If a button has a behavior attached to it, and the
 behavior script has a
 >>'before mouseUp' handler, can the behavior script
 also have a 'on
 >>mouseUp' handler?
 >>
 >>I could swear the answer was yes; I thought I had
 done that before, but
 >>now when I try it, it doesn't work. (In LC 6.5.x.
 and 6.6.0RC2). Instead
 >>I have to put the 'in mouseUp' in the button's
 script.
 >>
 >>Of course I might be completely missing the point of
 'before' and 'after'
 >>handlers. Wouldn't be the first time.
 >>
 >>Regards,
 >>
 >>Devin
 >>
 >>
 >>Devin Asay
 >>Office of Digital Humanities
 >>Brigham Young University
 >>
 >>_______________________________________________
 >>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
 >
 
 
 
 _______________________________________________
 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: before vs on in behavior scripts - red herring alert!

Devin Asay
In reply to this post by Devin Asay

On Mar 18, 2014, at 5:33 PM, Devin Asay <[hidden email]> wrote:

> All,
>
> If a button has a behavior attached to it, and the behavior script has a 'before mouseUp' handler, can the behavior script also have a 'on mouseUp' handler?
>
> I could swear the answer was yes; I thought I had done that before, but now when I try it, it doesn't work. (In LC 6.5.x. and 6.6.0RC2). Instead I have to put the 'in mouseUp' in the button's script.
>
> Of course I might be completely missing the point of 'before' and 'after' handlers. Wouldn't be the first time.

I think I figured out the problem, and actually my initial post was a red herring. There is still a little mystery. I had assigned behaviors to several buttons in my main project stack; the button containing the behavior script is in a library stack. So far so good. Everything worked the way it was supposed to. But later I came back into the project and added an 'on mouseUp' handler to the behavior script. However, the new ON handler never fired. (In fact, none of the handlers in the behavior script were being fired, and I couldn't invoke the debugger in the behavior script after placing breakpoints in it.) After a little tinkering I discovered that if I reassigned the behavior to just one the buttons that the handlers in the behavior worked again, for ALL of the buttons.

The red herring part happened because the BEFORE and AFTER handlers were being used to set up and down icon states in the buttons using that behavior. The icon states were always working properly when the ON mouseUp handler would not. Later I discovered that *someone* (I blame the code kabouters*) had gone in and assigned icon states to the buttons using the behaviors, rendering the BEFORE and AFTER handlers redundant. So I was left thinking only some of the behavior handlers were working, when in fact none of them were.

So it appears that each time I launch the project I have to reassign the behavior to the buttons. This only seems to happen for behaviors stored in library stacks. I have seen a similar problem with objects that were assigned a background pattern stored in a library stack. In that instance I finally had to add a line of code in my preOpenStack handler to reassign the bg pattern. Now it appears I'll have to do the same for these behaviors. But it doesn't seem right. Shouldn't I expect that buttons with behaviors contained in a library stack will always find those behaviors once the stack is reopened and the library stack has been start-using'ed? Or am I misunderstanding something (again)? Or maybe I stumbled upon a bug? Anyone know?

Devin

Devin Asay
Learn to code with LiveCode University
http://university.livecode.com



* kabouters = gnomes. In this case the Dutch have the far better word.



_______________________________________________
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: before vs on in behavior scripts - red herring alert!

Richard Gaskin
Devin Asay wrote:

 > Later I discovered that *someone* (I blame the code kabouters*) had
 > gone in and assigned icon states to the buttons using the behaviors,
 > rendering the BEFORE and AFTER handlers redundant.

I like "kabouters".  I have a friend who refers to unexpected behavior
in software as the work of faeries.  I imagine Brahmanathswami blames
the Menehuni.  I blame Coyote, the mischievous spirit the native
Californians blamed for the inexplicable annoyances of their world. :)


 > So it appears that each time I launch the project I have to reassign
 > the behavior to the buttons. This only seems to happen for behaviors
 > stored in library stacks. I have seen a similar problem with objects
 > that were assigned a background pattern stored in a library stack.

As much as I love behaviors, the finicky way they're resolved has been
an annoyance for me:  you have to make sure that any behavior script
objects are loaded before any object that uses them.

For example, if you have a mainstack which is an executable and contains
objects that use behaviors, and a separate library stackfile which
contains the behavior buttons, it will always fail because that
mainstack is opened before the library is loaded, so the resolution will
be attempted before the objects they resolve to can be known.

The workaround is as you've discovered: you have to write code to
reassign the behavior on the fly.

To simplify this occasional necessity, I had hoped the team would have
implemented a command they once talked about in the early days of
behaviors but never quite got around to: "resolve behaviors", which
would trigger the same resolution mechanism that happens when stacks are
first loaded, but could be called whenever you need it.

FWIW I submitted a request for that:
<http://quality.runrev.com/show_bug.cgi?id=8993>

--
  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
[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: before vs on in behavior scripts - red herring alert!

J. Landman Gay
In reply to this post by Devin Asay
On 3/20/14, 10:09 AM, Devin Asay wrote:
> So it appears that each time I launch the project I have to reassign
> the behavior to the buttons. This only seems to happen for behaviors
> stored in library stacks. I have seen a similar problem with objects
> that were assigned a background pattern stored in a library stack. In
> that instance I finally had to add a line of code in my preOpenStack
> handler to reassign the bg pattern.

My guess is: the engine looks for behaviors and other resources when the
main stack first opens (before any messages are sent,) then it gets the
command to open the libraries, and by the time that happens the main
stack has already finished looking for all resources.

If my theory is right, you wouldn't see the problem if you were using a
launch stack that loads the libraries and then opens the main working
stack. The libraries would be in RAM already in that scenario.

Maybe the engine could change the order so that it doesn't look for
resources until after preOpenStack is sent, but I'm not sure what the
internal repercussions of that would be. Might be worth a feature
request though.

--
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: before vs on in behavior scripts - red herring alert!

J. Landman Gay
In reply to this post by Richard Gaskin
On 3/20/14, 10:54 AM, Richard Gaskin wrote:
> To simplify this occasional necessity, I had hoped the team would have
> implemented a command they once talked about in the early days of
> behaviors but never quite got around to: "resolve behaviors", which
> would trigger the same resolution mechanism that happens when stacks are
> first loaded, but could be called whenever you need it.
>
> FWIW I submitted a request for that:
> <http://quality.runrev.com/show_bug.cgi?id=8993>

You're way ahead of me. We wrote our responses at the same time. Yours
is better.

--
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: before vs on in behavior scripts - red herring alert!

Devin Asay
In reply to this post by Richard Gaskin

On Mar 20, 2014, at 9:54 AM, Richard Gaskin <[hidden email]>
 wrote:

> Devin Asay wrote:

> > So it appears that each time I launch the project I have to reassign
> > the behavior to the buttons. This only seems to happen for behaviors
> > stored in library stacks. I have seen a similar problem with objects
> > that were assigned a background pattern stored in a library stack.
>
> As much as I love behaviors, the finicky way they're resolved has been an annoyance for me:  you have to make sure that any behavior script objects are loaded before any object that uses them.
>
> For example, if you have a mainstack which is an executable and contains objects that use behaviors, and a separate library stackfile which contains the behavior buttons, it will always fail because that mainstack is opened before the library is loaded, so the resolution will be attempted before the objects they resolve to can be known.
>
> The workaround is as you've discovered: you have to write code to reassign the behavior on the fly.
>
> To simplify this occasional necessity, I had hoped the team would have implemented a command they once talked about in the early days of behaviors but never quite got around to: "resolve behaviors", which would trigger the same resolution mechanism that happens when stacks are first loaded, but could be called whenever you need it.
>
> FWIW I submitted a request for that:
> <http://quality.runrev.com/show_bug.cgi?id=8993>

Thanks, Richard and Jacque,

I'm sure, somewhere in the cobwebby corners of my brain, there is a dusty memory of this discussion, but it takes me multiple times getting bitten by it to wrestle it from the grip of my inner slack-jawed yokel. I'll have to write a "poker" in my preopenStack script to force the resolution. I like Jacque's suggestion to load the libraries first, then the main project stack. I also like Richard's enhancement request, and I'd vote for it if we still had votes. It might not be a bad idea, Richard, to bump the version number up in the enhancement request to the latest release, maybe it'd get some attention.

Thanks all,

Devin



Devin Asay
Learn to code with LiveCode University
http://university.livecode.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: before vs on in behavior scripts - red herring alert!

Peter Haworth
In reply to this post by Richard Gaskin
On Thu, Mar 20, 2014 at 8:54 AM, Richard Gaskin
<[hidden email]>wrote:

> For example, if you have a mainstack which is an executable and contains
> objects that use behaviors, and a separate library stackfile which contains
> the behavior buttons, it will always fail because that mainstack is opened
> before the library is loaded, so the resolution will be attempted before
> the objects they resolve to can be known.
>
> The workaround is as you've discovered: you have to write code to reassign
> the behavior on the fly.
>

I wasn't aware of this issue but completely by chance I worked around it by
making my library stack a substack of the mainstack which uses it.  Of
course that won't work for all circumstances but happens to work for me.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
_______________________________________________
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: before vs on in behavior scripts - red herring alert!

Bob Sneidar-2
In reply to this post by Richard Gaskin
When I worked on Radars, many technicians were convinced there were electronic gremlins, because the rate at which the equipment suffered a failure within days before a missile test was uncanny. I am not superstitious, but by the time I was discharged, I was not ruling out the possibility.

Bob


On Mar 20, 2014, at 08:54 , Richard Gaskin <[hidden email]<mailto:[hidden email]>> wrote:

Devin Asay wrote:

> Later I discovered that *someone* (I blame the code kabouters*) had
> gone in and assigned icon states to the buttons using the behaviors,
> rendering the BEFORE and AFTER handlers redundant.

I like "kabouters".  I have a friend who refers to unexpected behavior in software as the work of faeries.  I imagine Brahmanathswami blames the Menehuni.  I blame Coyote, the mischievous spirit the native Californians blamed for the inexplicable annoyances of their world. :)

_______________________________________________
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: before vs on in behavior scripts

Dr. Hawkins
In reply to this post by Bob Sneidar-2
On Wed, Mar 19, 2014 at 8:16 AM, Bob Sneidar <[hidden email]>wrote:

> Actually, you need to down a few, and then all of this makes sense.
>

This is a good time to point out where quantum physics was developed . . .

You didn't find Professors Einstein, Plank, Boltman, etc. in their offices,
but in the bierhalls.

And, speaking as a physics major, noone would have come up with that stuff
sober . . .


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
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: before vs on in behavior scripts

Dr. Hawkins
On Thu, Mar 20, 2014 at 7:09 PM, Dr. Hawkins <[hidden email]> wrote:

> And, speaking as a physics major, noone would have come up with that stuff
> sober . . .
>

OF course, this is coming from an attorney who actually used Schrodinger's
Cat in his argument in Bankruptcy Court today . . .


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
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: before vs on in behavior scripts

mwieder

> OF course, this is coming from an attorney who actually used Schrodinger's
> Cat in his argument in Bankruptcy Court today . . .

You do realize, of course, that it's no good citing precedents in that
case...

--
-Mark Wieder
 [hidden email]

This communication may be unlawfully collected and stored by the National
Security Agency (NSA) in secret. The parties to this email do not
consent to the retrieving or storing of this communication and any
related metadata, as well as printing, copying, re-transmitting,
disseminating, or otherwise using it. If you believe you have received
this communication in error, please delete it immediately.


_______________________________________________
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
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: before vs on in behavior scripts

Dr. Hawkins
On Thu, Mar 20, 2014 at 7:41 PM, Mark Wieder <[hidden email]> wrote:

> > OF course, this is coming from an attorney who actually used
> Schrodinger's
> > Cat in his argument in Bankruptcy Court today . . .
>
> You do realize, of course, that it's no good citing precedents in that
> case...


It is, or it isn't, but we don't know until he rules . . .

(and the result was so good that I had a very rare beer with lunch . . .)


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
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