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 <d...@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 > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
