Opened 11 years ago

Closed 11 years ago

#6175 closed defect (fixed)

GUI: "Grid View" Loader Triggers Immediately in Dreamweb

Reported by: raziel- Owned by: bluegr
Priority: normal Component: Engine: Dreamweb
Version: Keywords:
Cc: Game: Dreamweb

Description

ScummVM 1.6.0git (Oct 31 2012 16:18:17) Features compiled in: Vorbis FLAC MP3 RGB zLib Theora AAC FreeType2

Steps to reproduce:

1) Set save display to "Grid View" (it doesn't happen with "List View") 2) Launch the game 3) Load any save state to get into the game or start the game 4) Once in the game choose "Disk Menu" 5) Choose "Load"

at this time i should be able to choose from the grid of save states the one i want. Unfortunately all ScummVM is doing is immediatly loading the save state underneath the mouse pointer without letting me choose anything.

DreamWeb (CD/DOS/English)

AmigaOS - PPC - SDL - BE gcc (GCC) 4.2.4 (adtools build 20090118)

Ticket imported from: #3582582. Ticket imported from: bugs/6175.

Change History (8)

comment:1 by digitall, 11 years ago

Summary: Dreamweb: Problem with in-game loading and "Grid View"GUI: "Grid View" Loader Triggers Immediately in Dreamweb

comment:2 by digitall, 11 years ago

Replicated on Linux x86_32 with latest Git master i.e. This is not a BE issue.

I needed to set Graphics Mode to 2x, as otherwise Dreamweb is running at 320x200 and thus the Grid View Save/Load Chooser switches back to List automatically, but this occurs as raziel_ describes.

comment:3 by lordhoto, 11 years ago

It seems Dreamweb opens the save/load dialog, on mouse button down. Thus when the GUI is opened it will recieve a mouse button up event at the position where the 5th (mid own of lower row, only speaking about 640x400 here) slot of the page is selected. This trigger a button event which in turn will make the dialog select this slot and load the game.

comment:4 by digitall, 11 years ago

LordHoto: Thanks. I had come to the same conclusion and you can work round this by keeping the left mouse button depressed. You can then move to the relevant savegame and release it to load... but this should be fixed properly i.e. flush any pending mouse up events?

comment:5 by lordhoto, 11 years ago

Not sure how you want to flush pending events like this.

comment:6 by digitall, 11 years ago

LordHoto: Well as far as I understand this: The engine gets the Common::EVENT_LBUTTONDOWN event and acts on this to create and display a GUI::SaveLoadChooserDialog which instantiates a GUI::SaveLoadChooserGrid.

If the mouse is released quickly before this is displayed, the Common::EVENT_LBUTTONUP event is pending in the EventMan when the GUI dialogs appear and the pending event is handled by the GuiManager::runLoop() function and incorrectly passed down as an action to the PicButton Widget below the cursor, triggering an immediate load.

This looks to be another case of a problem that has happened before as the scummvm/gui/gui-manager.cpp line 308 within the GuiManager::runLoop() function contains a "workaround" for a simple case of "switching" i.e. <snip> while (eventMan->pollEvent(event)) { // The top dialog can change during the event loop. In that case, flush all the // dialog-related events since they were probably generated while the old dialog // was still visible, and therefore not intended for the new one. // // This hopefully fixes strange behavior/crashes with pop-up widgets. (Most easily // triggered in 3x mode or when running ScummVM under Valgrind.) if (activeDialog != getTopDialog() && event.type != Common::EVENT_SCREEN_CHANGED) continue; </snip>

Though we could fix this by changing the engine code to trigger the load on the Common::EVENT_LBUTTONUP, rather than DOWN... I think a more general fix in GUI is probably warranted... basically to flush pending events when the dialog changes between engine and GUI in this way... if possible.

comment:7 by bluegr, 11 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed

comment:8 by bluegr, 11 years ago

Fixed in 20afbe95e64b4368d1380a533598fea8aa90dbd5. We now wait for both mouse buttons to be up before the ScummVM save/load dialog is shown. The fix should be in the next daily version of ScummVM

Note: See TracTickets for help on using tickets.