This trait adds a new “Refit” button to the Main Map Toolbar. That button can be disabled, and I defined an image (“RefitButtonDisabled.png”) for that button when disabled. The button appearance (both enabled and disabled) is working as expected.
However, when I run the “Remove Unused Images” utility from the Module Editor Toolbar, the “disabled button” image is included in the list of unused images:
Note that the other 12 images which are listed as “unused” are also actually used by the module, but only via explicit file path references embedded within an HTML string for a Report Action trait. I can understand why the module might not spot those references and I don’t think it is worth “fixing” that issue. However, the “disabled button” image is directly referenced within the GKC trait, and I suspect the Vassal design intent is to detect this reference.
The (in development) test module can be found in my Dropbox here.
The newly added GKC in question (Description = “Perform Dawn refits”) was added under the “Toolbar buttons” folder of the “Stalingrad” Map Window. Interestingly, it seems that none of the fields defined in that GKC (only) can be found by the Editor “Find” (Ctrl+F) function; that may be a significant clue.
I suggest you ignore this second issue (regarding the Editor’s Find feature). I am seeing it occur only intermittently, and have not yet determined the pattern to that behavior. I did however see it start working again after I unchecked the (newly added) Regular Expression box in the Search dialog, so that may be a factor. I will continue to look for a reproducible test case and report back.
Meanwhile, the original issue regarding the Unused Images is easily reproduced (and easily ignored - low priority).
This is long-standing and, as you say, expected. As a workaround, I stick those images into a dummy Layer trait in a Prototype; et voila, they become “known” to the editor. This also happens to be a useful way to load said image files into the module.
The feature is aimed at a situation I was finding where I have a Property called “cName”. The standard search will also report BasicName. With, Regex search a more targeted search is possible; for example: .*\bcName\b.* will find all references to the word “cName”.
The feature just passes the search string directly to a Java function for matching a Regex. This I presume is why, with no Regex operations in a string, the Regex search looks for exact matches only (typically throwing up Properties only).
In summary, the Regular Expression feature is for when you want a narrowed down search, presuming that it’s worth the effort of composing a Regex for it.
Perhaps a coding problem will emerge but at the moment I think at least some UI or documentation update would help. Some thoughts I have,
A message advising when Regular Expression has been selected for a search and what that means.
Add some more info on the search panel by the Regular Expression checkbox.
Another example in the Help.
Perhaps, when there are no regex operands in the search box, checking Regular Expression could produce a more useful, but intuitive, search than it does now.
Suggestions welcome and I’m interested in what further you may find.