#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: |
Description
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 , 20 years ago
comment:2 by , 20 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 , 20 years ago
| Owner: | set to |
|---|
comment:4 by , 20 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 , 20 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 , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Summary: | New Volume Control Dialogue Error-Prone → ALL: New Volume Control Dialogue Error-Prone |
comment:7 by , 6 years ago
| Component: | --Unset-- → GUI |
|---|
I added a comment here by mistake: https://sourceforge.net/tracker/index.php?func=detail&aid=1153300&group_id=37116&atid=418823