bugs in showMessageBox

[akt]

Hi all. New to LOVE, so hopefully this is the right place to post bug reports. The game I'm working on needs to ask the user if they want to save an unfinished game, so I'm using the following code to create a "save changes" dialog:

Code: Select all

    local title = "Save the current game?"
    local buttons = {"Save", "Cancel", "Don't Save", enterbutton = 1, escapebutton = 2}
    local b = love.window.showMessageBox(title, "", buttons, "info", true)

But I ran into two bugs (I'm using 0.10.2):

1. This bug seems to be Mac-specific (tested on Mac OS 10.12.3). If the user hits the return or escape key to close the dialog then that key event is seen by my love.keypressed callback. Fortunately this bug is easy to avoid by calling love.event.clear() immediately after the showMessageBox call.

2. This bug seems to be Windows-specific (tested on Windows 7, 64-bit). If the user hits the escape key then the button value returned is 3 (should be 2). If they hit the enter key then the button value returned is 2 (should be 1). This is a much more serious bug because I don't see any way to work around it (other than avoid a 3-button dialog).

[Jasoco]

I've encountered the Mac bug myself. For some reason Löve processes the keypressed callback when dismissing the message box. It really should ignore it as it can cause unintended things if your game happens to also use escape to do something. Never thought about clearing the events to avoid it. But it could probably easily be fixed by the devs now that it's been mentioned.

[zorg]

2. This bug seems to be Windows-specific (tested on Windows 7, 64-bit). If the user hits the escape key then the button value returned is 3 (should be 2). If they hit the enter key then the button value returned is 2 (should be 1).

For my Ira Glass Quote project that i posted on the forums a while ago, i did encounter a bug with the escape key, though i haven't tested whether it does return a value or not (i just assumed it didn't) since the enter key supposedly returned the correct 1 for me, instead of 2 like you claim... I gotta go and test this; will report back with this asap (also, you should open an issue on the issue tracker, see the pink button at the top of the forums)

Edit: Yep, Win7 x64, No matter what i set enterbutton and escapebutton to, it's always 2 and 3.

[slime]

These are bugs inside SDL, so unfortunately there's nothing that can be done inside love's own source code to fix them - but you can and should post a bug report on the SDL bugzilla.

[akt]

... you can and should post a bug report on the SDL bugzilla.

I'm happy to do that (although I suspect it would carry more weight coming from one of the love devs).

Actually, the Win-specific bug has already been reported here. The report also includes a patch to fix the bug so maybe that fix could be merged into the next love release?

[darkmetalic]

We will follow the logic, you have 2 keyboard options (enter and escape), the third would be "none", but if it is nothing then it is "cancel" and should return zero (nil would be more beautiful), but does not return that because don't have an object to close the window. You have to press somehow. Imagine that you are in a touch screen device where there is no mouse and real keyboards, so it is not necessary to have a focus on a specific button for when tight it works. If you move to the side it will make a selection that only exists on specific systems and if you press enter will activate the selected one and not what you set in the table. I would solve this problem by removing the "Cancel", because "Don't save" would already be the same option (and no have bugs with two options). I've determined that if I pressed [enter] it would be the "Save", but I can move to the side in the message box and when pressing the [enter] I want the selected focus and not "save" option. While pressing [escape] (with more than 2 options), you do not cancel. So this is a framework problem that uses true keyboard.

[akt]

Sorry, but I didn't really understand most of your post. This bit is wrong though:

I would solve this problem by removing the "Cancel", because "Don't save" would already be the same option...

The game I'm writing is a fairly simple board game. If the user is in the middle of a game and decides to quit the app then I show the above "save changes" dialog. The Cancel button means cancel the decision to quit. The Don't Save button means go ahead and quit. The Save button brings up the standard save file dialog so they can save the unfinished game before quitting (at least it will when I figure out how to do that -- I'm somewhat surprised to find that love doesn't have any support for native save/open file dialogs!). These buttons are familiar to Mac users. On Windows I'll probably change the button order in the dialog to Yes/No/Cancel -- that's what I see in most Win apps (eg. Notepad++).

[Positive07]

Do you wanna save before quitting?
Yes / No / Cancel

Sounds good to me... Also there is lua-nativefiledialog which I have compiled and used fine with LÖVE.

Check this post for info on save dialogs

[CherryBit]

Do you wanna save before quitting?
Yes / No / Cancel

[...]

Just to be pedantic: using "Yes"/"No" choices for dialogs is poor UX design and requires the user to read and think more. Using actions ("Save", "Don't Save") as the button labels is much clearer and allows the user to make choices with less reading. It may seem minor but users are easily frustrated, especially when you're forcing them to make a choice.

[Positive07]

It is not for native Windows. Since we don't have the new dialogs.