Opened 19 years ago

Closed 19 years ago

Last modified 6 years ago

#1944 closed defect (fixed)

ALL: New Volume Control Dialogue Error-Prone

Reported by: SF/tbcarey Owned by: fingolfin
Priority: normal Component: GUI
Version: Keywords:
Cc: Game:


With the latest CVS build for Win32 [March 7 2005 12:13:50], the new volume display/control dialogue is often prone to resetting the volume to 0 when the volume increase hotkey is pressed. This never happens when pressing the volume decrease hotkey. I cannot give a method for reproducing this behavior since it seems to happen randomly, but still frequently. Just go into any game with any sound emulation besides Adlib [more on that in a moment] and try decreasing the volume slightly, then increasing it several times until the volume resets to 0. It happens to me every few times I increase the volume.

Secondly, the volume control seems to have no effect on Adlib emulation volume. Even if the volume is set to 0, the Adlib music still plays at full volume.

Ticket imported from: #1158465. Ticket imported from: bugs/1944.

Change History (7)

comment:1 by salty-horse, 19 years ago

I added a comment here by mistake:

comment:2 by eriktorbjorn, 19 years ago

It seems to happen when you press the hotkey only once, and lets the dialog time out. Though I'm not sure why since the first thing that happens when the dialog is created is that setResult() is called with the input value, so that's the value that should be returned by the dialog, and thus used as volume. At least that's what I thought.

Anyway, if I call setResult(_value) from ValueDisplayDialog::handleTickle() before calling close(), it seems to work. I don't have the time right now to figure out why it doesn't seem to work without.

comment:3 by eriktorbjorn, 19 years ago

Owner: set to fingolfin

comment:4 by salty-horse, 19 years ago

erik, your solution works. The reason for the odd behaviour is: ValueDisplayDialog dlg is created and the constructor is called. In it, _result is set to be the correct value. One line afterwards, when runDialog() is called, it starts a chain that leads to Dialog::open(). In it, the result is "initialized" to 0, reverting the constructor's work. If no value-toggling key is pressed at this stage, the time-out function is called, while the result stays 0.

Now that the root of the problem is known, a more elegant solution, one that will also prevent future problems, is to move the initialization of _result from open() to Dialog's constructor.

comment:5 by fingolfin, 19 years ago

No, that would not really be the more elegant solution, it would simply shift the problem and cause issues in several other cases.

The proper fix is to move the initialisation of the dialogs state to the open() method, where it belongs (I just was being lazy putting it into the constructor).

comment:6 by fingolfin, 19 years ago

Resolution: fixed
Status: newclosed
Summary: New Volume Control Dialogue Error-ProneALL: New Volume Control Dialogue Error-Prone

comment:7 by digitall, 6 years ago

Component: --Unset--GUI
Note: See TracTickets for help on using tickets.