Multiple Visibilities not showing up

[delivery guy]

DG, as a point of fact I quite often deliberately insert blank lines into my XML scripts in order to facilitate legibility for humans!

Blank spaces is not what i am speaking about. I use blank spaces as well. I am saying the text string instructions must be in 1 solid line. Then the vis tags will work every time and there is no need to ever use an extra Element bracket unless you want to hide more than 1 string or other entries.

A few years ago i came across this exact issue where my vis tags would not work and i found i was trying to make the instruction line in 2 lines causing the issue.

How it should be written

      <Text X="180" Y="60" Length="3" Font="LCD" FontSize="60" FontWeight="600" Bright="Yes" Adjust="Left" VerticalAdjust="Top" Multiline="No" Color="Orange">

This shows the string as a working string but if you add a vis tag the tag can't hide the code due to a break in this line.

      <Text X="180" Y="60" Length="3" Font="LCD" FontSize="60" FontWeight="600" Bright="Yes"
Adjust="Left" VerticalAdjust="Top" Multiline="No" Color="Orange">

Just trying explain what i mean as there may be some confusion on what i meant by page break!

Tom for you to see my results simply try these 2 codes i posted. They will both work for showing the string. Now add any visibility tag and try both of these codes and you will see 1 works and 1 does not.

 

[taguilo]

DG,

I'm afraid all of your conclusions regarding visibility and line break are very wrong, I believe mostly because of an unproper understanding on how the XML parser works.

I took some time and wrote a test gauge that you and everyone else can install and try to get the idea.

Just copy the gauge in Gauges folder, then in an aircraft of your choice add:

[Window Titles]
.....
windowNN=Visibility Test

[WindowNN]
size_mm=500,500
position=6
visible=0
ident=10222
gauge00=VisibilityTest, 0,0,500,500


Ok, let's see what we are talking about:

The first three elements do not contain <Visible> condition. Two of them have broken lines, and one of these even a break within a parameter definition (Color) :

    <Element>
        <Position X="6" Y="24" />
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>NORMAL STRING - STRAIGHT LINE</String>
        </Text>
    </Element>
    <Element>
        <Position X="6" Y="32" />
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center"
     
     
            VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>NORMAL STRING - BROKEN LINE</String>
        </Text>
    </Element>
    <Element>
        <Position X="6" Y="40" />
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="Wh
     
            te" Adjust="Center"
     
     
            VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>NORMAL STRING - VERY BROKEN LINE</String>
        </Text>
    </Element>

The second group of elements has a <Visible> condition which is FALSE (0) when the gauge loads, both straight and broken lines:

    <Element>
        <Position X="6" Y="48" />
        <Visible>(L:ClickTest)</Visible>
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>(VISIBLE STRING) - STRAIGHT LINE</String>
        </Text>
    </Element>
    <Element>
        <Position X="6" Y="56" />
        <Visible>(L:ClickTest)</Visible>
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center"
     
            VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>(VISIBLE STRING) - BROKEN LINE</String>
        </Text>
    </Element>

The third group of elements has a common parent <Element> with a <Visible> condition which is FALSE (0) when the gauge loads, both straight and broken lines:

    <Element>
        <Visible>(L:ClickTest)</Visible>
        <Element>
            <Position X="6" Y="64" />
            <Visible>(L:ClickTest)</Visible>
            <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="Yes">
                <String>(PARENT VISIBLE STRING) - STRAIGHT LINE</String>
            </Text>
        </Element>
        <Element>
            <Position X="6" Y="72" />
            <Visible>(L:ClickTest)</Visible>
            <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center"
         
                VerticalAdjust="Center" Multiline="No" Fixed="Yes">
                <String>(PARENT VISIBLE STRING) - BROKEN LINE</String>
            </Text>
        </Element>
    </Element>

The fourth group of elements does not have a common parent <Element>, but each one has a <Visible> condition which is TRUE (1) when the gauge loads:

    <Element>
        <Position X="6" Y="80" />
        <Visible>(L:ClickTest) !</Visible>
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>(VISIBLE STRING TRUE ON STARTUP) - STRAIGHT LINE</String>
        </Text>
    </Element>
    <Element>
        <Position X="6" Y="88" />
        <Visible>(L:ClickTest) !</Visible>
        <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center"
     
            VerticalAdjust="Center" Multiline="No" Fixed="Yes">
            <String>(VISIBLE STRING TRUE ON STARTUP) - BROKEN LINE</String>
        </Text>
    </Element>

The last group of elements has a common parent <Element> with a <Visible> condition which is FALSE (0) when the gauge loads, one of them also has a <Visible> condition itself, and both display a counter variable as well:

    <Element>
        <Visible>(L:ClickTest)</Visible>
        <Element>
            <Position X="6" Y="96" />
            <Visible>(L:ClickTest)</Visible>
            <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="Yes">
                <String>%((L:Counter,number))%!d! (PARENT+OWN VISIBLE STRING W/ COUNTER) - ST LINE</String>
            </Text>
        </Element>
        <Element>
            <Position X="6" Y="104" />
            <Text X="324" Y="7" Bright="Yes" Length="54" Font="Arial" Color="White" Adjust="Center"
         
                VerticalAdjust="Center" Multiline="No" Fixed="Yes">
                <String>%((L:Counter2,number) ++ d (>L:Counter2,number))%!d! (PARENT VISIBLE STRING WITH COUNTER) - BROKEN LINE</String>
            </Text>
        </Element>
    </Element>

Now, when the gauge displays, this is the first result:

The first group of elements shows as expected. Notice VERY BROKEN one changes its color because the break is in the color name. It seems the parser then uses the CR and LF chars as hex codes and displays the resultant color. Nice uh?

The second group does not show, also as expected, because the individual <Visible> conditions are FALSE (0) at gauge's load.

The third group does not show as well, because its parent <Element> has its <Visible> condition FALSE (0) at gauge's load.

The fourth group shows, even without having a parent <Element> , because the individual <Visible> conditions are TRUE (1) at gauge's load.

The last group does not show as its <Visible> condition is FALSE (0) at gauge's load.

When clicking on the T at the bottom right, (L:ClickTest) changes from FALSE (0) to TRUE (1):

And a new situtation is displayed:

The first group of elements shows as expected, nothing special here.

The second group still doesn't show because, even <Visible> condition is TRUE (1) now, it was FALSE (0) at gauge's load. This is the main issue's source of this entire thread!.

The third group now shows, because its parent <Element> <Visible> condition is TRUE (1).

The fourth group doesn't show because the individual <Visible> conditions are now FALSE (0).

The last group now shows, as expected.

Let's see what happens if the 2D window is resized :

Now the second group becomes visible, because the rezise forced all of the window elements to refresh their buffers!.


Hope this helps to clarify things out.


Bottom line: when testing <Visible> conditionals, don't use (A) vars because they can load TRUE or FALSE depending on flight conditions, aircraft model and reload/reset situations; use (L) vars as in this example, where it is certain that they will load FALSE.


Tom

 

[n4gix]

Nicely done, Tom. That clearly illustrates the affect of the actual topic of this discussion.

 

[lionheart]

Thanks again Tom.

 

[spokes2112]

Great Post Tom!

To put it simply a text string must be drawn within it's own element on gauge load before visibility can be used. Using nested <Elements> achieve this.

<Element>
<Visible> Condition </Visible>
<Element>
<Text String>
</Element>
</Element>

 

[taguilo]

Hi Roman,

Actually the parent <Element> is the one that needs to contain the <Visible> conditional. Your example won't show either, needs to be like this:

<Element>
<Visible> Condition </Visible>
<Element>
<Text String>
</Element>
..... or .....
<Element>
<Visible> Condition </Visible>
<Text String>
</Element>
</Element>


Tom

 

[spokes2112]

OOPS! Thanks Tom! It has been corrected.. Was the first post of the early morning (4:00am local) and not nearly enough coffee, so it seems.

 

[delivery guy]

Tom thanks for the extra investigating as you are 100% correct that a broken string instruction does not matter.
So i decided to investigate more today using your test code. And i see that indeed you had to re scale the 2D panel to bring it to life. I don't use 2D so in tested in both 2D and 3D. In 3D you can't re adjust the screen and so it will not show unless you use a Lvar that is reversed. So i took a look at my old coding again as i said in the previous post that i came across this issue 2 years ago and found a solution from a member here on FS Developer. But it has been a while and when i tested Bill's code i tricked myself thinking it was indeed the broken line. But now that i did some testing today i found some old coding that works. Read below for the fix!

My reply post #14 Is the secret to make any string that only uses font <String>WORKING TEXT STRING WITH VISIBILITY TAGS </String> so that you do not need an extra Element bracket for visibility tags.

DOES NOT WORK:

<String>DOES NOT WORK</String>

DOES WORK: (Simply make a space at the end of the text in the string. This is only needed when using text in a string! Make sure the Length="9" is correct and does not include the extra space.)

<String>DOES WORK </String>

The only reason i kept pushing on this topic was because i knew i had a "FIX" but for some reason post # 14 did not remind me at the time as i thought for some reason it was the page break.


You can use this update to see that is does indeed work!

    <Element>
        <Visible>(L:ClickTest)</Visible>
        <Position X="6" Y="48" />
        <Text X="124" Y="7" Bright="Yes" Length="13" Font="Arial" Color="White" Adjust="Center" VerticalAdjust="Center" Fixed="Yes">
            <String>STRAIGHT LINE </String>
        </Text>
    </Element>

    <Element>
        <Visible>(L:ClickTest)</Visible>
        <Position X="6" Y="56" />
        <Text X="124" Y="7" Bright="Yes" Length="11" Font="Arial" Color="White" Adjust="Center"


        VerticalAdjust="Center" Fixed="Yes">
            <String>BROKEN LINE </String>
        </Text>
    </Element>

Well after a lot of discussion and testing i think this info will be helpful as there is no need to use extra Element brackets for text strings. I agree that both methods work but since we never use extra brackets for code strings there is no reason to start using them for text strings.

 

[lionheart]

This is still a mystery in a sence. In the first place, not all gauges will require this. I have done gauges for years and have thick coded PFD screens that have no dual embedding. This simple Autopilot required this fix for some reason. For what reason, I have no idea. Perhaps the font? Perhaps the size of the font? Who knows. Total mystery. But thank the Lord (and Tom) for the fix to make it work.

 

[taguilo]

DG:

The extra space is not the key at all...the key is the the number of characters to display with the Length parameter.

For example, STRAIGHT LINE has 13 chars so if you write Length="13" the text doesn't show. Now, if you make the string of 14 chars by adding a space at the end, like <String>STRAIGHT LINE </String>, only the number of chars explicit in Length (13 in this case) are copied to the buffer, the string is expanded to fit in the display area and the effect is similar as when you resize a 2D window; finally the display is refreshed and the text shows.

You can obtain the same by writing <String> STRAIGHT LINE</String>, with Lenght="13" displays STRAIGHT LIN, losing the E char.
Or writing <String>STRAIGHT LINE</String> with Lenght="12", which displays STRAIGHT LIN as well.

Now, if you need to show a single text your solution works fine, right. BUT, as FS expands the text into the area defined by <Text X and Y> parameters, it becomes difficult to calculate a proper relationship between this area size and the lenght of the text defined. Besides, it is usual in many instruments to display more than one line of text in a list; in this case you need to maintain same, fixed <Text X and Y> and Lenght parameters for all the elements that display on the list. Otherwise you'll obtain this (with your example):

Instead of this (what I really need to display):

In my opinion, it is way more simple to directly use a parent <Element> with the <Visible> tag. But perhaps in Bill's example it might give the same result with the extra space.
And there are also other ways to use conditional visibility for text strings, the most simple is to put the condition directly within a <Text> or <FormattedText> string.

Tom

 

[delivery guy]

I was also going to mention that another method is just to put the condition inside the text string.

Ok i see what your saying Tom. By adding the extra space is like stretching the window which forces the buffer. So now it makes sense why this works.

So now we can say there is 3 ways to fix a non working visibility tag for text strings. Glad we worked all this info out as i feel i have gained 3 types of text visibility tag knowledge.

1. Use a command event inside the text string.
2. Use another Element bracket outside the original text Element.
3. Put a space at the end of the text inside the string.

Thanks Tom for sticking with this as knowing why some things work and others don't is done by testing and help from others. I guess when you put text inside a string and it's not a string code the buffer will not be active if a variable starts from 0. Which makes sense since there is nothing to kick it in gear when the aircraft first loads.