VASSAL 3.5.4-SNAPSHOT-bug14152-d22186aba
Dynamic Property - Prompt User
Set Global Property - Prompt User
BUG: For both of these commands, when CANCEL is selected the associated Key Command continues to propagate.
Expected behavior: CANCEL should be equivalent to “I changed my mind and didn’t want to click this command” and thus the key command should not continue to propagate.
Simple module showing the bug for both Dynamic & Global properties enclosed.
Dec 2024 (Vassal 3.7.15 WIN64)
This thread was never addressed by developers and bug still exists. Example below:
When running the module, if I select “Build German U boats” (note the default of 8), but change my mind and CANCEL - the BUILDSW key command continues to propogate in my module and builds 8 Uboats (even though I tried to cancel the action).
I have built in a workaround to this problem, but it prevents me from using a default other than 0.
Expected behavior:
Select the menu option
User prompt comes up
IF OK is selected, the key command should execute
IF CANCEL is selected, the key command should NOT execute
“No” means NO (not - I said no, but I really mean yes)
The issue is that the key command, here BUILDSW, is already in progress. “Cancel” here does not refer to canceling the key command but rather, only to canceling the input action.
And then, by design, BUILDSW continues on its merry way. I understand that to be part of the Vassal architecture and it would be messy to interfere with that (I stand to be corrected here, of course).
I propose to you an approach that works with Vassal as it currently is, perhaps you’ve already done this as a workaround.
Create a prior step, whereby the input is gathered and then tested before you trigger BUILDSW and set SWTMP with that input.
e.g.
Suppose you add a Dynamic Property called SWTMPinput.
And instead of the initial triggering action being BUILDSW you interpose a key command initBUILDSW.
Here’s some psuedo logic that uses those additions:
On the SWTMPinput DP trait,
initBUILDSW initialises SWTMPinput to null (assuming that null is invalid input) and then same initBUILDSW prompts for input as you currently have it.
A Trigger Action trait, conditional on {SWTMPinput != null}, triggers BUILDSW; the first thing BUILDSW does is set SWTMP to the value of SWTMPinput.
If this works as I expect, then to the user, it will achieve the effect of allowing their Cancel of the prompt to also cancel the BUILDSW action.
Mark - I already have a work-around. The issue is that CANCEL does not do what it should.
Imagine this problem in the editor. You make a change in the editor, then realize you have totally bollixed things up. You hit CANCEL and the editor saves your bollixed up work, rather than CANCELLING out.
This is clearly unacceptable.
I’m not a developer and don’t know the underlying code, it’s possible its not easily fixable. It’s also possible that it’s a trivial fix.
In V3, would like it to get fixed if reasonably easy. if not, would be good to have a developer state it’s too hard and can’t be done.
In V4, would like it acknowledged that CANCEL should NOT propagate the associated key command to prevent this issue in the future.
Korval, what you want would require a major rewriting of how the Trigger Action trait works. Currently, it just blindly sends off each command in sequence, and there is no mechanism for it to know the effects of the commands. Allowing cancelling the input of a property change dialog to cancel the rest of the Trigger Action would be a huge change which would require lots of work to make sure it didn’t break any existing modules, so I can guarantee it won’t happen with V3.
I’m responding because you asked, but I won’t do either of the things you’re requesting.
On the first point: I’m doing no further discretionary work on V3, regardless of the difficulty. Maybe you can convince someone else to, but it won’t be me.
On the second point: None of the above will exist in V4 in this form, so there’s nothing relevant to acknowledge. It isn’t worth much for me to say that constructs which there won’t be won’t behave in some particular way.
Could you disable or eliminate the CANCEL button?
Joel & JR - appreciate your response. No worries, given the difficulty and focus on V4.
