A little Levure-oriented question

[Graham Samuel]

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.

Graham

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 <use-livecode at lists.runrev.com> 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         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> 
> 
> On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode <use-livecode at lists.runrev.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?
>> 
>> Graham
>> 
>>> On 21 Feb 2018, at 22:33, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> 
>>> The target.
>>> 
>>> Bob S
>>> 
>>> 
>>>> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode <use-livecode at lists.runrev.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
>>> use-livecode at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode