Challenge: how to set the text of a field

Peter M. Brigham pmbrig at
Sat Mar 30 08:45:41 EDT 2013

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
pmbrig at

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 <david at> 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 at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list