Some things about backgrounds i never knew

[David Bovill]

Thanks for the replies Andre and Jim!

On 30 December 2010 10:38, André Bisseret <andre.bisseret at wanadoo.fr> wrote:

>
> Look at  "backgroundNames" in the doc:
> ---------------------
> Comments:
> The backgroundNames is the list of all backgrounds in the stack whose
> backgroundBehavior property is set to true, whether they appear on the
> current card or not. If a group in the stack contains groups, only the
> top-level groups are reported.
>
> To find out which groups are placed on a card, use the groupNames property.
>

Yes - this is what I thought. What i did not get is that what is happening
here is such a hack, that is there are two important concepts / behaviors of
backgrounds:

   1. It is shared across many cards and changing a property of one changes
   the property of all ie they are the same object and have the smae id)
   2. The message path is different

These seem however not to be linked, or related directly to the various
built in functions ie  backgroundbehavior / backgroundnames / backgroundids
- so in the examples mentioned in previous posts you can have a background
shared across serveral cards that has it' background behavior turned off and
therefore does not show up in the backgroundnames / backgroundids. This is
problematic in the handlers I am writing now - as I want to know whether to
export the background or not, so I can;t rely on any of the built in
functions.


On 30 December 2010 10:37, Jim Ault <jimaultwins at yahoo.com> wrote:

>
> 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.
>

Yes - I think you're right there, and there are no built in functions to
detect how many "shared background objects" there are in a stack - only how
many have their "behave like a background property" turned on or off.


> 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)
>

This last part I don;t get yet... seems so strange I think I must be making
a mistake somewhere. These are the results I get (all result in true):

   - put the number of bgs of this stack = 2
   - put the number of bgs of this card = 0  -- this is wrong !
   - put the number of groups of this stack = 3
   - put the number of groups of this cd = 3

This is for a card in the stack that has 3 groups, comprising of 2 top level
groups, and one inner group, both of the top level groups are "shared
background objects" as they appear on the first card of the stack and the
third card. Therefore there are indeed 2 backgrounds, and 3 groups, all
though why there are 0 groups on the card is any ones guess.

The real thing that makes no sense is that these 2 backgrounds (note 2 not
3), are the wrong bgs, that is not the two top level bgs - but for some
totally random reason the they are the two groups of the nested background.
Why - I don't know - because it is nested? Because it was created first?

So the real question for me right now is what does "bg 2 of stack" actually
refer to? Perhaps it is "the second group in the current stack" - but what
does that mean? It is not the second top level group, as this is not even
showing up, and changing the layers of the groups makes no difference - so
it looks like the only thing that makes sense is the order of creation for
bgs - but still?

So the question is that given there must be a numbered index of bgs
associated with a stack:

   - how are bgs added and removed to this index?
   - what determines the order of elements in the index?