Text labels in 3.2.0: bug or feature?

Text labels in 3.2.0 seem to behave differently from what they did in 3.1.x. See also this other thread (text label centering bug): http://www.vassalengine.org/forum/viewtopic.php?f=3&t=4839&p=30194&hilit=text+label+offset.

Specifically, if I had a single piece in an at-start-stack, containing a succession of text labels and nothing else (all with default alignment and offset settings) then in Vassal 3.1.x they would show one above the other whereas in 3.2.0 they overwrite each other in a single garbled line of text.

To bypass the latter problem I guess one has to define offsets. But is this really a feature, i.e. it was a bug in 3.1.x, or is it a bug in 3.2.0?

If possible I would vote to go back to the old behaviour… as I use such a long succession of text labels in a single piece to print out debugging information in some private development window… Having to manually tweak and tune each and every offset is a pain in the neck, generally speaking. Could it be made a checkable option in the text label trait? Like: use/don’t use offsets (the latter being the old “one above the other” 3.1.x printing style).

Fixed by Brent Easton today (see build 8228): text labels are now again printed one above the other as in 3.1.18.
Thanks Brent!

On 28/07/2012 9:33 AM, barbanera wrote:

Fixed by Brent Easton today (see build 8228): text labels are now again
printed one above the other as in 3.1.18.
Thanks Brent!

Although this is just a chance byproduct of the fact the Labels with no
key command are included in the shape of the clickable unit. If you add
key commands to the labels, the labels print on top of each other.

Brent.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Thus spake barbanera:

Text labels in 3.2.0 seem to behave differently from what they did in
3.1.x. See also this other thread (text label centering bug):
Text labels bug? - #5 by barbanera
+label+offset.

Specifically, if I had a single piece in an at-start-stack, containing a
succession of text labels and nothing else (all with default alignment
and offset settings) then in Vassal 3.1.x they would show one above the
other whereas in 3.2.0 they overwrite each other in a single garbled
line of text.

To bypass the latter problem I guess one has to define offsets. But is
this really a feature, i.e. it was a bug in 3.1.x, or is it a bug in
3.2.0?

If possible I would vote to go back to the old behaviour… as I use such
a long succession of text labels in a single piece to print out
debugging information in some private development window… Having to
manually tweak and tune each and every offset is a pain in the neck,
generally speaking. Could it be made a checkable option in the text
label trait? Like: use/don’t use offsets (the latter being the old “one
above the other” 3.1.x printing style).

I don’t have a clear idea of what problems you’re seeing with text
labels at this point.

What we need from you is a test module and a description of what
we’re supposed to see.


J.

Here is the test module: [attachment=0]text_labels.vmod[/attachment]
It includes a single at-start-stack containing a single piece. The piece contains 4 text labels, without key commands to change them (default trait with just the “Text” line at the top changed).

Vassal 3.1.18 shows:

Text1
Text2
Text3
Text4

Vassal 3.2.0-beta1 shows:

(a single garbled line with the 4 strings overlapping)

Vassal 3.2.0 starting with build 8228:

Text1 Text2 Text3 Text4
Hope it is clear now.

This is bug 4632 which should have been fixed in svn 8228.

Thus spake barbanera:

Here is the test module: text_labels.vmod
Vassal 3.1.18 shows:

Code:

Text1
Text2
Text3
Text4

Vassal 3.2.0-beta1 shows:

Code:
(a single garbled line with the 4 strings overlapping)

Vassal 3.2.0 starting with build 8228:

Code:
Text1
Text2
Text3
Text4

Hope it is clear now.

So this means all of the text label problems are solved, then?


J.

Well, this one was solved for me, even though I learned I won’t be possible to rely on automatic line feeds between text labels, should I define command keys on them.

However, I don’t know if/when the text centering bug was addressed by anybody, but I don’t think so:
[url]https://forum.vassalengine.org/t/text-labels-bug/4630/5]

So I encountered a Text Label related bug in svn 8258 just now, it is probably unrelated to this issue but I’ll post here anyway.

I have 2 text labels one is set to position Vertical, Top, Offset 15 x Horizontal, Right, Offset 4. The 2nd label appears just underneath it with the values Vertical, Top, Offset 30 x Horizontal, Right Offset 4. So, same Horizontal offset but 15 pixels lower. In svn8258 that 2nd text label is drawn about 30 pixels or so to the right of where it is supposed to be, so it is no longer lined up with the top row. The properties for it are identical to before.

The same module, opened in svn 8221 does not produce this error.

Thus spake barbanera:

Well, this one was solved for me, even though I learned I won’t be
possible to rely on automatic line feeds between text labels, should I
define command keys on them.

However, I don’t know if/when the text centering bug was addressed by
anybody, but I don’t think so:
Text labels bug? - #5 by barbanera
+label+offset

When did this start?


J.

January 27th, 2012, 5:28 pm

Thus spake barbanera:

January 27th, 2012, 5:28 pm

I mean what was the first version in which you saw this problem?


J.

Thus spake chrono280:

So I encountered a Text Label related bug in svn 8258 just now, it is
probably unrelated to this issue but I’ll post here anyway.

I have 2 text labels one is set to position Vertical, Top, Offset 15 x
Horizontal, Right, Offset 4. The 2nd label appears just underneath it
with the values Vertical, Top, Offset 30 x Horizontal, Right Offset 4.
So, same Horizontal offset but 15 pixels lower. In svn8258 that 2nd
text label is drawn about 30 pixels or so to the right of where it is
supposed to be, so it is no longer lined up with the top row. The
properties for it are identical to before.

The same module, opened in svn 8221 does not produce this error.

Post a test module showing the problem.


J.

Thus spake barbanera:

January 27th, 2012, 5:28 pm

Also please post a test module showing the problem.


J.

Joel, maybe this discussion about the “centering” bug should be moved now to the relative thread (see link in a previous post), at any rate I can confirm that I noticed this bug back in January this year, when strictly using Vassal 3.1.18. Moreover, I have just checked and it’s still there in 3.2.0 build 8249.

I created a test module to demonstrate it (includes hot women pics!):
[attachment=0]text_label_centering_bug.vmod[/attachment]
(instructions in the module when you run it).

While I was at it I added the demonstration of some lurking issue with the “line feed” bug/thing (to which this thread was originally dedicated): having a text label only printing something like $FOO$ gives a new line with the content of $FOO$ - even when empty - but only if not followed in the trait order by another text label with some actual static text. Otherwise, it will overlap the following text label in the trait order (which is actually printed first). Is this as expected…? Note that if the following text label does not have static text, but rather just something like $BAR$, both $FOO$ and $BAR$ will appear on their own lines (no overlap).

Thus spake barbanera:

Joel, maybe this discussion about the “centering” bug should be moved
now to the relative thread (see link in a previous post), at any rate I
can confirm that I noticed this bug back in January this year, when
strictly using Vassal 3.1.18. Moreover, I have just checked and it’s
still there in 3.2.0 build 8249.

I created a test module to demonstrate it:

text_label_centering_bug.vmod

(instructions in the module when you run it).

While I was at it I added the demonstration of some lurking issue with
the “line feed” bug/thing (to which this thread was originally
dedicated): having a text label only printing something like $FOO$ gives
a new line with the content of $FOO$ - even when empty - but only if
not followed in the trait order by another text label with some actual
static text. Otherwise, it will overlap the following text label in the
trait order (which is actually printed first). Is this as expected…?
Note that if the following text label does not have static text, but
rather just something like $BAR$, both $FOO$ and $BAR$ will appear on
their own lines (no overlap).

Is this still a problem in 3.2.0-svn8397?


J.

YES, still a problem.

If any work at all was done on text labels since this report, then it didn’t address these problems at all.

Thus spake barbanera:

YES, still a problem.

If any work at all was done on text labels since this report, then it
didn’t address these problems at all.

Please put this into the bug tracker, then.


J.

I searched the tracker and it looks like there is a bit of a mess regarding the text label situation. Therefore, I am unsure if/what to add to the tracker as a genuine new bug.

I have come up with the following (biased) list of open issues;

  1. There is a “centering” bug, dating back to 3.1.x and discussed in various threads and finally reported as bug 4322 by David Robert, who even looked at the code, found it was a caching issue and proposed a fix. Check his test module or my test module here. Still open.

  2. There is a “unselectable” bug with text labels on pieces which have no imaged defined, reported as bug 4600, but the jury is still out on this (bug or no bug? feature request?).

  3. There is a “overlapping” bug with multiple text labels, which come up with early 3.2.0 builds. Brent looked at this and presumably (see below) fixed it from build 8228. However, he did add it as bug 4632 to the tracker, with status FIXED, but he quoted the wrong text: he mentioned the centering bug instead.

  4. There is possibly a “dynamic vs static” bug, discussed in this same thread, when showing multiple text labels, some printing things like $FOO$ (originally empty) and others printing static text, which end up overlapping again… this is NOT in the tracker yet but it might be the same as bug 4600 or as bug 4632, or a combination of the two… (see test module in this thread for this as well).

  5. There is a “delayed” bug with text labels which print things like $FOO$ and don’t get updated till every other command (e.g. GKC’s) is fully resolved, whatever the position of the Set Global Property or Dynamic Property trait that changes the value of $FOO$ is in the trait order. This is NOT in the tracker yet (and I think there is an exact similar issue with the Layer trait not refreshing till the very end).

  6. There is a hard to pin point “timing” bug with trying to have a scrolling log made of multiple text labels printing things like $LOGLINE1$, $LOGLINE2$ etc which shows up when the command moving LOGLINE2 to LOGLINE1 (i.e. scroll up) sometimes does not happen (the new LOGLINE2 text gets overwritten over the old one). NOT in the tracker (and might be related to issue (5) above).

Ok,

I have found and fixed the centering problem. This was quite straight forward, when the text changed, the position of the label was not being recalculated. This is bug 4322.

I believe most of the rest of the bugs relate to the incorrect way you use Text labels barbanera. On reflection, I believe the fix I made for 4632 was incorrect and that the way it was before (that caused your overlapping labels problem) was correct.

If two labels are defined with the same offsets then they should appear in the same place. Full stop.

If you want labels to appear on different lines, then you should be specifying an offset in the label to make them appear on different lines.

The fact that labels with no key command happen to appear on multiple lines in the past was basically a bug in my view that should have been squashed as soon as it appeared.

Regards,
Brent.