Thanks Peter - but no it does not help. Lets take your example, but what we want to do is give the group a (virtual) custom property that a developer can call from anywhere in the environment to retrieve the text in the field. You can't hard code anything like you have " fld "f" of card 2" - as you have no idea which stack or card a developer will put the group on.
You want to be able to issue somethign like the following from the message box, or a button, or handler from any stack in the environment: put the field_Text of group "g" of card 2 of stack "Test" There is no way to script a handler of any sort in the group that can do this. You can't even do it with sending, or calling a command. AFAIK it's that simple - basic, important and can't be done. Or can it :) On 30 March 2013 12:45, Peter M. Brigham <pmb...@gmail.com> wrote: > 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 > _______________________________________________ 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