Jacque always dishes out common sense IMHO. Thanks for that. I would shield you
from the flying fruit if I could.
I guess my heretical thinking is based on two ideas:
1. Setting the behavior of an object (my Big Green Button) looks just like
scripting it to me: I mean for this to work, the object has to be qualified by
a reference to something outside its local environment: OK, it’s not exactly
code, but it seems to me philosophically similar. So the UI stack is tied,
however lightly, to the SOS undergrowth.
2. When I’ve used behaviors myself, it’s to allow essentially the same script
to be used for many objects, with the extremely useful ability to hang on to
the local context: I once used behaviors for cells ina spreadsheet-like
display, for example - whereas in my current example, I proposed that the Big
Green Button was unique and wouldn’t want to share its primary handler with
anyone else (though of course it would probably use some common library
routines in any complicated set up). If in my example there was a Big Red
Button, it would have an entirely different function from the Green one, so
there would be no room for the shared code a behavior provides. So the use of
behaviors in this kind of setup looks kind of forced to me. But perhaps I am
overestimating the extent to which behaviors come into the picture.
Changing the subject a bit, I once wrote a very simple DC circuit simulator, in
which there were different components like a light bulb, a motor, a buzzer etc.
When the user ‘switched’ the circuit on (by clicking on an object representing
a switch), the program sent the same message - “applyVoltage”- to each object.
Each object had its own applyVoltage handler (method, in O-O parlance) for
reacting to the circuit going live, so the bulb lit up, the motor rotated etc.
This is kind of the inverse of the behavior idea - this is the same message
being sent to multiple objects rather than multiple objects using the same
script. I wonder how a Levure-framed app would deal with such a structure.
Perhaps it wouldn’t notice at all.
PS My UK spell checker **really** wants behavior to be behaviour, but this is
not among its synonyms, regrettably.
> On 22 Feb 2018, at 06:20, J. Landman Gay via use-livecode
> <firstname.lastname@example.org> wrote:
> I'm not a purist, I'd put the handler in the big green button. Especially if
> it's short. There are no hard rules about this stuff.
> I suppose I'll have to dodge flying fruit now.
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode
> <email@example.com> wrote:
>> It’s very late here, so a brief reply to a brief reply. I know about ‘the
>> target’. Believe it or not I also know about behaviours and can use them.
>> But if I have a Big Green Button in my UI, I want a handler which does
>> something if and only if the Big Green Button is clicked on. Obviously in my
>> SOS I can have some ‘universal’ code that says something like
>> if the target is “bigGreenButton” then
>> do something related only to this particular object
>> But isn’t that just making the whole thing more complicated than it need be?
>> Maybe I will understand this clearly in the morning - who knows?
>>> On 21 Feb 2018, at 22:33, Bob Sneidar via use-livecode
>>> <firstname.lastname@example.org> wrote:
>>> The target.
>>> Bob S
>>>> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode
>>>> <email@example.com> wrote:
>>>> But if there’s no code in the UI stack, how do the handlers in the SOS
>>>> know what object has invoked them?
>>> use-livecode mailing list
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>> use-livecode mailing list
>> Please visit this url to subscribe, unsubscribe and manage your subscription
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription