Some things about backgrounds i never knew

[Jim Ault]

I don't have a specific answer for this set of questions, but durning  
a holiday week few may be available to answer.. so here goes.
I rarely use groups as backgrounds for my projects.

You may be in the land of
    synonyms
    backward compatible to HCard
    oddities of groups
    message path priorities

Note: (from the dictionary)
When referring to a group using the synonyms background, bkgnd, or bg,  
the reference is to one among the groups in a stack, rather than to  
one among the groups on a card.
For example, the object reference background 1 indicates the first  
group in the current stack, not the lowest-layered group on the  
current card.

-----
In my mind, 'behave like a background' does not mean become a  
background object.
Groups can be shared, placed, and removed from any card in the stack  
that contains the group.
The groups reside in the stack
... thus
>   - put the number of bgs of this stack = 2
is the same thing as saying
      - put the number of groups of this stack = 2
(which is true in your case)

The other part of 'background' that is important is the message path.   
Setting behavior to true should mean that its script is placed after  
the card, rather than before the card.  This is critical when  
designing complex user interfaces.  Others have discussed 'oddities'  
when using nested groups and the message path.  Perhaps they can chime  
with their discoveries and techniques.

If all of the groups have their behavior set to false, then  
backgroundnames = empty
Again, synonyms of 'group'
There can be 20 groups defined in a stack and not one of them placed  
on any of the cards.
There can be 8 groups defined in a stack, all of them placed on every  
card, but none of them specified as "background behavior" and none of  
their scripts will occur after any of the card scripts.


Hope this leads you to clarity.


On Dec 30, 2010, at 1:31 AM, David Bovill wrote:

> OK - it's morning and I still don't get it.
>
> In my simple test stack, I have 3 groups and 3 cards. One of the  
> groups
> (group "Inner") is inside another, and both top level groups (group  
> "First
> background" and group "Second Nested Background") are on the first  
> card and
> the last card, all though they have had their background behavior  
> set to
> false.
>
> The following are all true:
>
>   - put the backgroundnames of this stack = empty
>   - put the number of bgs of this stack = 2
>   - put the short name of background 1 of this stack = "First  
> background"
>   - put the short name of background 2 of this stack = "Inner"
>
> It makes no sense that "the backgroundnames" is empty and the number  
> of bgs
> = 2. It also makes no sense that the second bg is not the second top  
> level
> group that is shared across several cards, but is an inner "group"  
> of a
> nested background.
>
> Can anyone make sense of this? I'm sure a bug like this would have  
> been
> spotted before?
>
> On 30 December 2010 00:02, David Bovill <david at vaudevillecourt.tv>  
> wrote:
>
>> Now I'm lost...
>>
>> You can even create backgrounds that are (almost) impossible to  
>> detect. If
>> you create a top level group called "Hidden background" and then  
>> "remove" it
>> from the card - it will appear in the backgroundids /  
>> backgroundnames of the
>> stack even though it is not visible on any cards.
>>
>> However if you then:
>>
>> set the backgroundbehavior of bg "Hidden background" to false
>>
>> it will not only not be visible, it won't show up in the  
>> 'backgroundids /
>> backgroundnames of the stack".
>>
>> Looping through each background number by using "the number of  
>> backgrounds
>> of stack" gives a completely different result, which at the moment  
>> is making
>> no sense... for instance I have go a test stack with two shared  
>> groups -
>> both of which I've turned off the backgroundbehavior (so the  
>> backgroundnames
>> is empty) - no bg 1 of stack is the first group, but bg 2 of stack  
>> is an
>> inner group and not the second shared group.... maybe it will make  
>> sense in
>> the morning....
>>

Jim Ault
Las Vegas