Nested <Area> tags in XML

[rpmc]

Nested <Area>, XML FS9 schema

I only now discovered this useful capability that allows me to define click area Left and Top positions relative to another Left and Top definition. Analogous to what you can do with <Element>. But I wonder, does anybody know the rules for using it?

<Area Name="MAP BUTTON GROUP" Left="200" Top="100">

     <Area Name="TERRAIN TOGGLE" Left="0" Top="0" Width="20" Height="20">
         Stuff 1
     </Area>
    
     <Area Name="MAP ROT" Left="430" Top="0" Width="20" Height="20">
         Stuff 2  
     </Area>  

     <Area Name="PAN TOGGLE" Left="455" Top="0" Width="20" Height="20">
         Stuff 3
     </Area>    
    
     <Area Name="ZOOM BUTTON" Left="480" Top="0" Width="20" Height="20">
         Stuff 4  
     </Area>    
    
</Area>

The Left and Top positions of the 4 click areas are relative to "MAP BUTTON GROUP" Left="200" Top="100" which is very helpful to me as I move Element and Click Area groups around while designing my gauge.

However, I guess you can have only 3 such nested <Area> constructions in the <Mouse> section, and if a fourth is added, you lose the mouse click capability of the first group - only the bottom 3 are valid. AFAIK, <Element> has no such limitation.

Do I have that right? Any other rules?

Bob

[Edit]. See response #7 below. 3 nested <Area> limit is not correct

 

[n4gix]

Bob, I've never personally used more than one 'nested area' myself, so honestly do not know. The major benefit as you've noted is that the "sub-areas" are indeed relative to the parent's defined 'area'.

 

[spokes2112]

I believe one can refine it a bit by providing the main area loc, size height etc.. Reducing the other child attributes.

<Area Name="MAP BUTTON GROUP" Left="200" Top="100" Width="120" Height="20" >

<!-- Width 20 with 10 px spacing -->

<Area Name="TERRAIN TOGGLE" Left="0"  Width="20">
Stuff 1
</Area>

<Area Name="MAP ROT" Left="30" Width="20">
Stuff 2
</Area>

<Area Name="PAN TOGGLE" Left="60" Width="20">
Stuff 3
</Area>

<Area Name="ZOOM BUTTON" Left="90" Width="20" >
Stuff 4
</Area>

</Area>

Or one could split a parent area in half easily (From FS9 Vega)

<Area Left="105" Top="236" Width="63" Height="62">    
      <Area Right="32">
       Stuff 1
      </Area>
   
      <Area Left="31">
        Stuff 2
      </Area>

    </Area>

 

[rpmc]

Thanks Bill and Roman. One other 'ah-ha', in nested <Area>, it appears that you can't use negative numbers in the child attributes. Too bad. In nested <Element> this is allowed, and I use it frequently.

 

[taguilo]

But I wonder, does anybody know the rules for using it?

Yes Bob, I use to know that rules some time ago that I had to code a complex INS completely in XML.

When dealing with many related <Area> sections one advantage, if I recall right, is that you can set visibility of the entire set of nested areas in the parent, ie:

<Area>
  <Visible>script</Visible>
   <Area1/>
   <Area2/>
   <Area3/>
</Area>

Tom

 

[n4gix]

Yes, and I used that neat feature a LOT when scripting my G1000 PFD and MFD units. That was the only practical way to script the multi-function softkeys!

 

[rpmc]

Yes Bob, I use to know that rules some time ago that I had to code a complex INS completely in XML.

When dealing with many related <Area> sections one advantage, if I recall right, is that you can set visibility of the entire set of nested areas in the parent, ie:

<Area>
  <Visible>script</Visible>
   <Area1/>
   <Area2/>
   <Area3/>
</Area>

Tom

Thanks everyone,

Understanding nested Area behavior. Trial and error.

<Visible> is interesting. In my gauge, I was using <Visible> in the child <Area> but not in the parent. So, to see what happens, I put a <Visible> in the parent too, which turned out to be fatal: Crash To Desktop. In some cases, the sim crash occurs when the gauge loads and other cases, when a mouse area is clicked. Don't mix <Visible> in both parent and child <Area>.

Also, I was wrong about the 3 nested <Area> limit. Three was just a coincidence.

My error was defining only Top and Left in the parent - analogous to X=" " and Y=" " when using nested <Element>, but omitting Width and Height in the parent. Apparently, that’s a mistake, even though Top, Left, Width and Height were always defined in each child <Area>.

If Width and Height are not also defined in the parent, then it seems that FS assumes the parent <Area> is large, maybe extending to the bottom right of the gauge. Consequently, there will be parent <Area> overlaps if you have multiple nested <Area> groups like I have, and that will result in some groups not working.

I need to define Top, Left, Height and Width in each parent <Area> and make sure that this area does not overlap with any other parent <Area>.

Cheers,

Bob