Text labels in 3.2.0: bug or feature?

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.

Bug 4600 was closed as Won’t Fix. There is a standard way to achieve what you are trying to do.

I’m not sure why this is significant. As long as at the end of the command stream, the appropriate labels are displayed, what is the problem?

The actual time that any image is redisplayed under java is out of our control, we can only request Swing to refresh a screen area or component, the actually timing of refreshes is handled by Java. If you are trying to implement some type of animation effect through Vassal Key Commands, you are doomed to failure.

Regards,
Brent.

Thus spake Brent Easton:

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.

Fixed in 3.2.0-svn8417. Try that.


J.

Brent, I wholeheartedly agree. Indeed, I made an attempt (back in January) to properly define offsets. However, and here is the catch, then there is a bug with offsets. Or maybe I don’t understand how to use offsets…

Piece with multiple text labels:

  1. first text label at default vertical offset 0

  2. second text label at 10

  3. third text label at -10

All the rest being equal (default selection for alignment etc) they should appear one on top of the other 10 pixels a part, correct? They don’t. And they didn’t work properly even in early builds of 3.2.0, that is before your fix to revert to 3.1.x automatic line feeding style.

That’s why I was happy with the 3.1.x behavior that automatically added line feeds between them. It was contrary to the whole point of having offsets, sure, but then please fix the offsets situation or tell me what I am doing wrong :slight_smile:

Anyway, there is an obvious drawback to having to calculate and define offsets (when they actually work): you can’t just add another text label and/or change the respective font size of the existing ones without having to go through a whole bunch of calculations and one-by-one fiddling.

Maybe giving the piece component a “do not stack text labels” (or “add automatic line feeds between text labels”) check-able attribute would be nice. Or perhaps make it a map or module level property…

Yes, I know, the invisible gif. But then one has to predetermine needed length of the invisible gif and keep changing it whenever he changes his mind about the string to display. I think this is cumbersome and ugly and needlessly adds (potentially) tons of small invisible gifs to the module. But of course it is hard to implement otherwise then I am pretty happy with the ugly workaround, it’s not a crucial issue at all.

I have a “Click here to start the game” piece with an action button which a player in a network game pushes to initiate a complex setup process. What I am trying to achieve is for the button itself to revert to “… game starting, please wait…” and then to proceed to the actual setup (which takes a minute or so) before deleting itself.

I tried using a Layer or a Text label which follow the value of a Dynamic Property called “Status” defined on the piece (tried also with a global property) and having the action button first thing change it from 0 to 1, before proceeding to invoke the rest of the setup procedure via a bunch of triggers.

The problem is that people (including the player pushing the button) won’t ever see the “… game starting, please wait…” image/string because it won’t change till the very end, when it actually deletes itself. Thus, players will keep pushing the button not knowing if the game started or not till the very end. No way to achieve this then, I gather? I also tried Replace with Other, but no cigar.

Moreover, remote players will not even get the update of the “Status” DP/GP from 0 to 1 till the very end, so that they will disrupt the setup procedure by initiating it themselves while setup is already in progress (resulting in out of synch setups). But I guess this is another story… (wish somebody had a clue how to solve it… how to force a resynch on the fly…).

Confirm centering bug fixed, thanks!

Change your method and force it to pause instead at the “game starting please wait” by requiring the user to click the action button again and changing what the text says so you might have

step 1 - “Click here to Setup Game”
step 2 - “Setup complete - Click here again to begin play”

Hmm, how would this solve the problem?

The problem is the actual lengthy setup, which you suggest to do in step 1. How would everybody (including the clicking player) know the button was actually pressed till the very end if there are no visual clues about it right away? This is just the original issue. It is not crucial in solo mode (just a bit ugly): after all restrict commands are in place to block the player from clicking multiple times. However, in network play it completely breaks the game if some remote player bona fide clicks “start game” again (no visual clue, no update yet of the DP/GP tracking the click).

Similarly, if step 1 is just a label replacement (from “Start game” to “click to continue”) the problem will again arise exactly as before in step 2.

On Wed, Oct 10, 2012 at 6:55 AM, barbanera barbanera@fantafoot.com wrote:

Anyway, there is an obvious drawback to having to calculate and define
offsets (when they actually work): you can’t just add another text label
and/or change the respective font size of the existing ones without
having to go through a whole bunch of calculations and one-by-one
fiddling.

Yes, that is a problem with absolute layouts in general.
But short of having some sort of automatic layout definition, it isn’t easy
to solve.

One solution to the font size issue, though, is to allow font-relative
units to be used. Something like “ex” and “em” for spacing. IIRC the
JGoodies layout manager has a provision for that based on Microsoft’s (?)
“dlu” (dialog units) measurement.

Look at what I did in the Urban Sprawl module - click on the 2 setup deck
buttons and watch the chat window and what the buttons do. Exactly what you are
trying to do here. Use the chat window to communicate the internal process -
everyone will see it


From: barbanera barbanera@fantafoot.com
To: messages@vassalengine.org
Sent: Wed, October 10, 2012 12:55:47 PM
Subject: Re: [messages] [Developers] Text labels in 3.2.0: bug or feature?

“Tim M” wrote:

Change your method and force it to pause instead at the “game starting
please wait” by requiring the user to click the action button again
and changing what the text says so you might have

step 1 - “Click here to Setup Game”
step 2 - “Setup complete - Click here again to begin play”

Hmm, how would this solve the problem?
The problem is the actual lengthy setup, which you suggest to do in step

  1. How would everybody (including the clicking player) know the button
    was actually pressed till the very end if there are no visual clues
    about it right away? This is just the original issue. It is not crucial
    in solo mode (just a bit ugly): after all restrict commands are in place
    to block the player from clicking multiple times. However, in network
    play it completely breaks the game if some remote player bona fide
    clicks “start game” again (no visual clue, no update yet of the DP/GP
    tracking the click).

Similarly, if step 1 is just a label replacement (from “Start game” to
“click to continue”) the problem will again arise exactly as before in
step 2.


Read this topic online here:


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages