And here is the textDisplay object for the field “Output”.
For some reason, the textdisplayobject in PanX treats alpha text differently from numeric text - the numeric text output seems to ignore the tab between entries. The tab still is there if one uses the variable - but the tab isn’t shown in the textdisplayobject. There is also a phantom line-return that sometimes appears in the display, so that an single line of a text array will output as two lines.
PanX correctly uses the output, so this is merely a format issue. But does it suggest an underlying issue, Jim? By the way, Pan6 properly displays the above code. I have the latest update of PanX, with MacOS High Sierra.
I do not think that alpha text is treated differently as numeric text. Instead I imagine the tab is treated like 4 letters. Since your number text is exactly 4 letters long, the next tab position is immediately next to the first number.
Try to use a different number format with e.g. a number format with a leading zero. I bet then you will see the tab distance.
There is a tab between the 9.35 and the 2nd 9.35 but it is taking up less gap than you want. And that is why they often use monospaced fonts. You will see this same non aligned issues in any word processor.
The extra line-return is not due to wrapping but some how related to a limitation in the maximum width of the text when a tab is encountered. Here is a line of text with several tabs and no returns that ends up on two lines even though the Text Display is plenty wide enough to accommodate all of it on one line. It is set to No Wrap as well and uses this code:
It looks like there is a limited number of tab stops per line. It went looking for the next stop, and found it on the next line. Notice how “of” is indented.
I don’t think it is the number of tabs but it is triggered by the first tab beyond a certain length of text. This text with only one tab latter in the text still triggers the unwanted return:
“Now is the time for all good men to come to the aid of their party, Now is” +¬+ “the time”
Not the number of tabs. It’s the number of tab stops. If your first tab occurs after the third stop, then the next character will be on the fourth stop. The gap created by any tab will depend on the distance to the next stop. Sometimes that distance looks like no gap at all. Sometimes it looks like the distance that would normally be taken up by four characters, and if it is past the last stop, it will be the first stop on the next line.
But these are “not seeing trees for forest” explanations.
The point of my example is that for each line:
1- the number of tabs is identical
2- the number of alpha-numeric characters is identical
3- the spacing is identical
4- the length of each element in each line is identical
The ONLY difference is that the first line uses numerical text, while the second uses alpha text. I had always thought that using double-quote marks made everything in between TEXT. So that, “7” is treated no differently than “h”. But apparently, that is not so.
Numeric-text somehow retains a ghost of its essence. PanX “remembers” that the text was once numeric, and treats it differently. The only reason I brought it up is that there may be a subtle clue here on something else that needs attention.
Is this in any way related to why character formatting for the data sheet (italics, bold, etc.) is so hard to implement, Jim?
In your example, the difference was simply that 9.35 was slightly narrower than Note, because the decimal point was narrower than the letters and numbers. This allowed the second 9.35 to start one stop earlier than it would have if the first one had been 9335, instead of 9.35.
OK, Dave. I guess I thought that a decimal point was a holder of a text position, no different from any other holder. But I see that text width is important.
I changed the font of the text display object to Monaco, and sure enough, the two lines are now formatted the same. But note the ghost carriage-line return. I’m sure Jim has other things to occupy his time rather than this minor format issue.
I just tested this in a Text Display set to Monaco and found that a tab after 43 characters does not trigger the extra return but after 44 characters the tab adds a new line.
This discussion is missing the elephant in the room – tab stops are not supported when using a Text Display object with plain text. I don’t believe there is anything in the Panorama documentation that would lead anyone to think this was supported.
If you want to use tab stops in a Text Display object you’ll need to use Rich Text, and explicitly set up the tab stops you need.
In this case, however, it seems to me that your application is begging for you to use a Text List object instead of a Text Display object.
In any case, tab stops in plain text are definitely going to produce inconsistent results.
Then you were just lucky. Panorama 6 did not support tab stops at all (except in the word processor object).
