'send' and behaviors

Graham Samuel livfoss at mac.com
Mon Jun 4 10:05:14 EDT 2012


Thanks Dar - I guess your 'A' is the way to go, and I'm doing it (more or less). I don't see how to do 'B' in a way that very simply returns control to the original caller (CardX) without extra code in the handler asking "do I have to go back to CardX or not?", which I think would be even more messy than 'A'. Anyway the horse has probably been flogged enough. Thanks also to Peter Haworth for reminding folks that I started all this because the LC documentation led me along. I think it is at least arguably wrong, and I will consider it a bit and then post a comment.

Cheers

Graham

On Sun, 3 Jun 2012 14:28:58 -0600, Dar Scott <dsc at swcp.com> wrote:
> 
> I hope I'm not adding more confusion.
> 
> I see a couple directions for a solution.  There are probably other ways.
> 
> A.  In your behavior scripts sprinkle 'of me' throughout.  
> 
> B.  Lock screen and move to the card at the start of the handler and then move back and unlock at the end.
> 
> Dar
> 
> If the latter, then if you do have to make changes, 
> On Jun 3, 2012, at 2:04 PM, Graham Samuel wrote:
> 
>> Thanks again to Mark, Dar and Ken to replying. What a lot of good advice! Let's hope I'm clever enough to follow it. While I'm studying your comments, I thought perhaps a little more explanation is in order, because I still don't think I've explained myself properly. If you're getting bored, stop reading!
>> 
>> In some ways, what I'm doing is a bit like running several spreadsheets. There are several datasets, each one represented by a small set of cards. Each card has its own behavior, but of course this behavior is repeated for all cards of the same function, so that for example there's a data set
>> 
>> Set_1_CardA
>> Set_1_CardB
>> ---
>> Set_1_Cardn
>> 
>> and other datasets with the same pattern, e.g.
>> 
>> Set_4_CardA
>> Set_4_CardB
>> ---
>> Set_4_Cardn
>> 
>> All the "CardA" cards have the same behavior, and this works beautifully because any object references in the behavior script operate in the context of the particular card that's being used, so I don't have to work out which card I'm operating on when I'm running the behavior script - that's the intention of behaviors. Say that in a particular card type, perhaps CardB, there is a handler (say "doSomeSums") that was conceived as operating on that card. Its job is to do some calculations on the the fields of the card and stick something in some other fields to show totals etc. The user invokes this card to do data entry, and the handler shows him the results. Every time new data is inserted, the calculation is re-run within the context of the card. Some of these results may depend on information on other cards in the set. So far so good.
>> 
>> Now I find I have another card type (say CardX) that, as it were, presents a summary of summaries. Because I am not quite sure if the user has actually visited all the necessary cards in the set, and I'm therefore not sure if the intermediate results have been generated as I want, I want to go round the houses again, running "doSomeSums" or the equivalent on the various cards in the dataset - but I want to do this without CardX losing control. That's where the 'send' commands come in. I just want to cycle round all these calculating handlers in the different card types, executing them within the context of the appropriate card in each case, to make sure that all the fields that CardX needs within the entire dataset are completely up to date. (Spreadsheets do similar things all the time - and they make intelligent guesses about the required order of evaluation of cells, but I'm not going that far.) While processing for CardX and displaying its results, I am not interested in !
>> opening the other cards at all - the user might do that at some point, but then my summary calculations would have to be re-done anyway.
>> 
>> I simply want to run "doSomeSums" and its friends knowing that within the handler, where there are lines like
>> 
>> put fld "AA" into fld "BB"
>> 
>> they will not need further qualification because the context has been set for them.
>> 
>> I think from what I've been told (but I really am still studying it) that this is just plain impossible in LC; so I need to rewrite the handlers in the behaviors to be more context-aware, possibly using the techniques suggested. It's not really that hard, but it doesn't have the generality I'd hoped for.
>> 
>> Sorry for the bandwidth
>> 
>> Graham
> 




More information about the Use-livecode mailing list