Try this: - create a new stack with a button "test" and a field "f" - group them in group "g" - set the backgroundbehavior of group "g" to true - create 2 new cards -- the group will be placed on all 3 cards - put "one" into fld "f" of card 1, "two" into fld "f" of card 2, "three" into fld "f" of card 3 - create a button "behav" on card 1 - set the behavior of group "g" to the long id of btn "behav" of cd 1 - set the script of btn "test" to the following:
on mouseUp put fld "f" of card 2 end mouseUp Click btn "test" and you get "two" in the messagebox Does this do what you want? -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Mar 30, 2013, at 6:54 AM, David Bovill wrote: > Tried everything I can think of call, send, value, even the > executioncontexts - there is simply no way you can code this in the script > of the background (or the groups behavior). makes no difference if it is > just a shared group or a background. It comes down to the target always > referencing the current card instead of the card you are actively targeting > in the script (as in grp 1 of card 3) - that is except of course there is > no shared group on the current card in which case is does what yo would > expect and the target actually targets the "grp 1 of card 3" > > Since everything uses this there is no way for a handler to know it was > called using the form "put the card_Number of grp 1 of card 3" rather than > "put the card_Number of grp 1 of card 2" - and so no way for it to return > the text of the group on that card or the hilite of a button on that card - > none, zero. > > This makes it impossible to code widgets for shared backgrounds. If I want > to return some simple text - I can do something like "put the text of the > title_Field of grp 1 of card 2" - but if I want to do something complex > like return an array with all the data that the group is displaying - no > go, no way, not possible. > > It's enough to abandon the idea of creating such groups and stick instead > to a single card paradigm, bringing the data in by creating new groups on > the fly. > > > On 29 March 2013 21:07, David Bovill <da...@vaudevillecourt.tv> wrote: > >> OK - lets rename the challenge :) Same problem - but defining it as >> follows: >> >> - Is it possible to create a handler in the behavior of a shared group >> that returns the number of the card the shared group is on? >> >> This is the same problem - it is a problem of finding a reference to the >> card a control is on so that you are able to return values of properties of >> the group such as a hilite or text that can differ from card to card. As >> far as I know there is actually no way at all to do this. >> >> Although I thought parsing the long id works - it does not. So the >> following handler does not work. >> >> getprop card_Number >> put the long id of the target into targetObject >> repeat >> if word 1 of targetObject is "card" then >> put the number of targetObject into cardNum >> return cardNum >> end if >> delete word 1 to 4 of of targetObject >> if targetObject is empty then return empty -- just in case >> end repeat >> end card_Number >> In fact the behavior of references to shared "background" groups is quite >> bizarre! Take the following experiment - create a shared background and >> place it on 3 cards - add the handler above to the script of the shared >> group. It can be the behavior of the group or its script. >> >> Now given you are on the first card - issue the following from the message >> box: >> >> put the card_Number of group 1 of card 3 --> answer is 1 >> put the card_Number of group 1 of card 2 --> answer is 1 >> put the card_Number of group 1 of card 1 --> answer is 1 >> >> Now try removing the group from the first card, and do the same again: >> >> put the card_Number of group 1 of card 3 --> answer is 3 - ie correct! >> put the card_Number of group 1 of card 2 --> answer is 2 - ie correct! >> put the card_Number of group 1 of card 1 --> well there isn't one so you >> get an error >> >> Summary - this is a bug. It also makes it impossible to define some basic >> and useful behaviors for shared "bakground" groups. >> > _______________________________________________ > 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 _______________________________________________ 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