Text Label in At-Start Stack and impossible selection

Hello all,

I suppose my question will seem a bit of a noob one, but I am beginning to lose all understanding I supposed I had concerning Vassal Modules.

I am currently trying a simple thing: an editable text label in an At-Start Stack where you can put your name with the “Change Label” command integrated with the Text Label trait. My issue is that I can not select the piece when I define the shortcut for the Change Label menu item whereas I can select it if I leave the shortcut empty…

There is nothing more in the piece than the basic piece trait (with a name but no image), then the text label trait and a delete trait (that appears correctly if I leave the shortcut empty for Change Label).

I would gladly receive any advice you could give to me! And sorry if it is a stupid question :slight_smile:

Well, I just made a quick test and I, for one, can confirm 100% what you say!

I found that it only works if you define an image on the piece. Otherwise, if you leave it undefined/invisible then even the delete trait will disappear (but only when the change label command is defined), just as you say.

I tried with both 3.1.18 and 3.2.0 beta 1 (with the latter I even tried changing from a combo key (was using CTRL-A) to a named command on the change label, but no difference).

To work around this bug I suggest you create an invisìble gif of roughly the same size in pixels as what you expect the text label to be.

As a side note - but this might be a known bug not yet fixed even in 3.2.0 beta 1 - when you define an image, then remove it again… you are then stuck with the impossibility of defining it yet again. The image previously used shows in the pull down menu choice (indeed it’s there in the Images folder in the module), but selecting it makes no difference: the image remains undefined (=invisible piece). I think you need at least 2 images in the folder so to actually change the default showing in the basic piece trait or it cannot be assigned an image ever again. You need to remake the piece from scratch. Two bugs in one go?

Thanks a lot for your answer ;) It is working now, so I can continue my work!

Thus spake barbanera:

As a side note - but this might be a known bug not yet fixed even in
3.2.0 beta 1 - when you define an image, then remove it again… you are
then stuck with the impossibility of defining it yet again. The image
previously used shows in the pull down menu choice (indeed it’s there in
the Images folder in the module) choice but selecting it makes no
difference: the image remains undefined (=invisible piece). I think you
need at least 2 images in the folder so to actually change the default
showing in the basic piece trait or it cannot be assigned an image ever
again. You need to remake the piece from scratch.

File a bug report, or it will never get fixed.


J.

Right, reported both bugs: 4599 and 4600.

Incidentally, since I read that Vassal 4 is going to be so much different and everything… can you clarify if it will build on 3.2.x to add/fix stuff - with all major changes being under the hood - or should we expect a complete new product?

I suppose it is the former, but I was wondering if it was the latter … and hence my reluctance in filing bug reports (if the present engine is at the end of the line).

Thus spake barbanera:

Right, reported both bugs: 4599 and 4600.

Incidentally, since I read that Vassal 4 is going to be so much
different and everything… can you clarify if it will build on 3.2.x to
add/fix stuff - with all major changes being under the hood - or should
we expect a complete new product?

There will be a module converter for V4.

I suppose it is the former, but I was wondering if it was the latter …
and hence my reluctance in filing bug reports (if the present engine is
at the end of the line).

I definitely want to fix any bugs which are new in 3.2. I’m planning to
circle back soon (maybe next week?) to take care of the ones for which
we have reports, before releasing 3.2.0-beta2. I don’t intend to work on
bugs which predate 3.2 myself from here on. That doesn’t mean nobody
else will and I’m still perfeclty happy to have patches for old bugs, as
I suspect that the 3.2 series will be in use for some time before V4 is
ready.

So, please do continue reporting bugs.


J.

Hi,

Have had a look at 4600 and I don’t believe it is a bug.

The pop-up menu appeatrrs when Vassal detects that you have right-clicked on the counter image. Since you are not defining any image for the counter, it is impossible for Vassal to detect that you have clicked on the counter. Hence no pop-up menu.

You counters are not ‘Invisible’ ( a bad term, since in Vassal, it means a counter turned invisible by the Invisible trait), but are non-existent.

The way to do what you want is to use a fully transparent image of the apprropriate size (say 50x50 or 75x75) as the Basic Piece image of your counter. This will keep the body of the counter from having any visible image, but when you click on it, you will see get a right-click menu appear and the shape of the transparent image will be outlined by the Selection Highlighter.

Bug 4599:

Can you just confirm that this is a problem if and only if there is just the one image in the entire module?

The problem lies in the fact the the image only gets selected when the drop-down list item changes. With only one item, it can never change.

You can always reload the single image by double-clicking on the image display panel. It doesn’t help that the image display panel dissappears when teh dialog repacks after the image is deselected. You can manually resize the dialog and double click where the image is usually displayed.

I can see two ways to approach this

  1. The quick way is to have the ‘Double-click here to add new image’ message re-appear when you deselect the current image by cancelling the image picker.

  2. The longer way is to Add a new ‘(No Image)’ option at the head of the image list that is displayed when you first create a piece, or when you deselect the image. Selecting the ‘(No Image)’ option will also deselect the image.

My initial thoughts where that since this only occurs in the one image situation, that option 1 was the way to go.

However, given the current non-intuitive method of deselecting an image (by starting to load an image and then clicking cancel), I’m thinking that option 2 is probably worth the effort. In fact, both option 1 & 2 together would probablty be best.

Thoughts?
Brent.

Bug 4599:

yes, I also think option 1 would be best (or both 1 and 2).

Bug 4600:

Again, I don’t think you have read this thread through and/or maybe my bug report was not much clear. ;) ;)

The piece we are talking about are not non-existent: they have a text label defined printing out some actual text. Thus they have some sort of physical presence. Indeed, as he said in the original post, and I confirmed in the 2nd post, traits like DELETE do show up when right clicking on the text label. They do. If this is a bug, and the piece should really be non-existent, I don’t know. But surely it looks more like a feature to me (the fact that a text label alone gives a “presence” to a piece even without an image defined).

The bug, instead, is that those other traits like DELETE stop showing up when you define a command key to change the text label. Why would the theoretical possibility of changing the text all of a sudden make the piece completely non-existent?

Yes, the workaround is to use an actual invisible image, again something already suggested in the thread (2nd post). :slight_smile:

Brent, can I ask that you look at bug 4302 next, when you have a chance? Unless somebody else is taken care of this, that is.

It is a bug related to global hotkeys not respecting order of execution (jumping the line) in network play for the remote clients. It is very painful to work around, if possible at all.

As an example (but this is a relatively painless one) suppose a trigger on your units fire an hotkey to move forward the turn counter after a moving/action is done on the piece. Then the report trait associated with the turn counter will show up first on the remote computer, which is rather confusing/ugly:

Local client: Tank fires on infantry - Turn finished
Remote client: Turn finished - Tank fires on infantry

This same example becomes much more painful if you have any extra “intelligence” in the module to change state when the turn moves on, as it will change it too soon on the remote client.

Bug 4600 - The Selection of Labels.

The problem is that when a Label command does not have a Control key, the image of the label is taken to be fixed and a part of the selectable shape of the counter.

When a label command does have a Control key, then the label is assumed to be variable and is excluded from the selectable shape of the counter.

Normally, this is not a problem unless you have no image defined at all in which case the only thing defining a selectable area is the Label when the Control command is not defined.

The Delete command seems to ‘dissappear’ when you add a Label control key because the label is no longer selectable and so the right-click find nothing.

Ok, I understand.

However, I personally think that it is a nice feature to have pieces with no image defined and a variable text label selectable (and hence right click commands and all). Without the need for the transparent gif work around… why forcing the extra work?

Even should dynamically changing the size of the selectable area prove too difficult/impossible, just having it set to cover the initial preset string is better than having to remember creating and adding a transparent gif of the same size (what if one changes idea about the font size later on etc).

As always, the problem is compatibility with existing modules where the designers have set up the module to work in a certain way and should reasonably expect that the way it operates does not arbitrarily change to suit someone else.

One possibility would be to have a new checkbox option in the Label trait to the effect of ‘Always include label in selection area’ to change the default behaviour.

Note that there is the danger that if a user changes the label to nothing, the counter becomes completely innaccessible.

I’m moving discussion of bug 4302 to a new thread.

The checkbox would be optimal, agreed.

Have submitted a fix for bug 4599:

  • added ‘(No Image)’ option at head of list to deselect image via combo box
  • Ensure ‘Click here’ message re-appears when image deselected
  • Fixed dialog packing when no image selected