Dialog buttons and user control issues

Not sure if this is common knowledge already, I will admit that I only searched briefly with three queries regarding the subject matter.

In any case, from what I have seen of the few maps I have played, no one attempts to circumvent this issue. I just now randomly decided to post about it despite abusing it since ages ago.

It is a single issue, but it has two problems that spawn from it.

The problem is that users can press dialog buttons more than once before the button actually disappears (ie, send more than one click event). The circumstances this would unintentionally happen (ie, the user is not trying to do so) are probably rare, but nonetheless, it has happened to me several times.

For maps that do not check for legitimate button presses, this can be an issue. Examples include the Ice Escape maps, in which users can select several heroes at once, the Fate / Another II maps, in which users can vote several times to kick (or not kick) a player when the appropriate dialog shows, and The Predator, in which a player can select several predators at once during selection time.

Besides the above issue, there is also the issue that clicking a dialog button more than once in this manner results in the user losing the ability to order his units around and such (can still chat and decide to share unit control, however). The losing control problem occurs even if the button has no attached events; in other words, if you simply create a dialog button and show it, the user clicking it more than once causes them to lose control.

The issue with users losing control can easily be resolved with enabling user control via the appropriate JASS function (whose name I do not recall).

As for running into these problems during normal play, for me it usually occurs if I happen to click several times while the game spikes for a moment (thus sending in several clicks at once to the button; my habit is to click repeatedly and quickly). It can also be deliberately done by a user in full screen, one can simply tab out of Wc3 then tab back in, clicking repeatedly while Wc3 is in progress of tabbing back in.

To easily see this problem in action, one can simply attach ollydbg to Wc3, hover the mouse over a dialog button, pause execution, click several times, then unpause.

Well, the issue is a slightly obscure one, but maps not checking for it can allow abuse (or ruin the game for a single player if he cannot control his units anymore). The losing control is not really a problem for me since I use TFTL, but it nonetheless annoys me when players sometimes complain about no longer being able to do anything in game.

Guess I will add to this a somewhat related issue (related to dialogs, anyway).

You probably want to avoid using victory/defeat dialogs in your maps. A feature in TFTL that was deemed amusing at the time actually backfired on me once in the past, ironically. In regards to TFTL, the situation basically occurs as follows: user turns on /nokick, user is "defeated" via a victory/defeat dialog, user clicks any of the available dialog buttons, everyone without /nokick active is removed from the game (sans the user). This functionality was an unintended feature, but it brings to light some issues with dialog boxes that might have been unnoticed or obscure.

The process Wc3 goes through when throwing a victory/defeat dialog is something like this (viewable in the blizzard.j):
1) Create a victory/defeat dialog for all players
2) Desync target player(s) of dialog
3) Show victory/defeat dialog for target player(s)
... and so on

TFTL circumvents the second step, making the target player(s) send the button click event to all players, resulting in the leave code being executed for everyone.

Besides TFTL, there is another theoretical issue with this situation. Step 1 has the dialog created for all players, but it is only shown for one player. Thus, every player is aware of this dialog's existence and select events on it. From there, after the first victory/defeat dialog is created, in theory, any player could use it to kick every other player in the game.

Making a hack or some such to show the dialog locally is trivial stuff.

Random knowledge, how fun.

This is indeed very useful information. It is quite easy to assume that if you hide a dialogue when a button-click event occurs, further button clicks can not take place. The loss of control on multiple clicks is quite a tricky bug itself, it's good to know about that. Thanks for writing this.