Calling order after selecting menu item is wrong

Hi there,

I think the calling order when a menu item is selected is not aligned between documentation and actual behaviour.
The documentation states:

Source: Inside Playdate

However the actual implementation appears to be (i.e. steps 2 and 3 are swapped):

  1. Hide the System Menu
  2. Unpause and call playdate.gameWillResume
  3. Invoke callback of menu item

Here is a minimal LUA project to show this: (4.3 KB)
It will add a menu item "test", which when selected will print two lines into the developer console:

I think the behaviour described in the documentation is preferable. Having the menu item callback be called first, allows the developer to react to it and change the behaviour of the gameWillResume callback before it is called (which might do something differently compared to when the menu is just closed without a menu item being selected). Otherwise this would be harder to reproduce (i.e. the gameWillResume callback would have to just set a flag, which then is checked next update call alongside a flag set by the menu item callback to invoke the correct behavior...)

So I would love to see the implementation changed to match the documentation.

I have reproduced this with Firmware 2.1.1 in the emulator and on actual hardware.



I agree that it makes more sense as it's documented. Unfortunately, changing the way it works could break existing code. I'll file an issue to fix the docs, but how about I also add playdate.gameDidResume() that gets called after the menu callback?

Yeah that would also work.
I was thinking of naming it something more descriptive like gameWillResumeAfterMenuCallback(), but that looks like it would only be called after a menu callback. So I guess either is fine.

Thanks Dave.

Hi there,
unfortunately this bug / documentation error stills persists in Version 2.2.0.
Any idea when it will get addressed? Is there a better place for me to report it (like a bug tracker or whatever)?

I've got it filed in the issue tracker, but can't give an estimate when we might have a fix in. (There are currently 1,278 open issues. :anguished:) I'll post a note here when we do!

Hi Dave,

thanks for the update.
1278 issues sounds crazy for such a small team and I can totally understand that this issue is not a top priority. So no worries there, all I hoped for was some confirmation this has not been lost and this is what I got.

FWIW, I would happily contribute to the code or even just the documentation if it were open source. Issuing a pull request for such a tiny matter takes as much (or even less) time as discussing it here on the forums.
Maybe this is something for the team to consider, if the number of issues keeps rising.