'send' and behaviors

Dar Scott dsc at swcp.com
Sun Jun 3 15:28:58 CDT 2012


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
> 
> 
> _______________________________________________
> 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




More information about the use-livecode mailing list