Expected Result: I expected a MenuItem's PDMenuItemCallbackFunction to be called before the eventHandler() as the C API documentation states here - Inside Playdate with C
Actual Result: eventHandler() was called before PDMenuItemCallbackFunction when using playdate->system->logToConsole inside an if(event == kEventResume)
@dave Should the documentation be changed or the behaviour?
I was intending to set an extern flag in a PDMenuItemCallbackFunction when selecting a menu item and then checking the extern flag in eventHandler() within an if(event == kEventResume) block in order to set some game state e.g. show in-game settings screen.
I haven't had a chance to dig into the source yet, but when you say Win 10 Simulator only do you mean it works differently on the device? Or you've only tested it on the simulator so far?
Could this be explained by the buffering behavior of logToConsole()? To test that, you can increment a static variable in both places and log whichever place turned it into a 2 in order to work around the buffer timing.
Works correctly on the device, too. The _exitMenu() function that runs when you select a menu item first calls the "unpause and notify" function which sends kEventRelease to the capi handler, then calls the selected menu callbacks. I don't see any way those could get reversed.
If you have a reproducible test case, can you please post that? That'll be the best way to get this sorted if there's an actual problem here.
The issue is that the documentation states that the menu callback is called before the kEventResume event.
Original post:
Expected Result: I expected a MenuItem's PDMenuItemCallbackFunction to be called before the eventHandler() as the C API documentation states here - Inside Playdate with C
Aha! Thanks, I'll file that. And then go work on my reading comprehension.
We can fix the docs or change the call order.. I think I'll go with the docs so we're not changing existing behavior, unless anyone has a good argument for doing the callback first.
Yes, the problem with doing kEventResume first is that you can't do something in kEventResume with the menu item data. E.g. storing the option that was selected in an extern and doing something with that value. Currently the menu item data always gets set after kEventResume fires.
The kEventResume callback and the menu callback are called one after the other from the same context, so the only real difference is if we do kEventResume first you don't know if the menu item was selected or not--if it was you get the resume callback then the menu callback, otherwise just the resume callback. I can kind of see how that could be a problem in a very specific case? But I'm not sure it's worth the risk of breaking existing code if we change it. If you're already setting a flag in the menu callback to pass it along, could you handle it in the update callback instead of resume?
Yes I did end up just picking up the value change in update which means that kEventResume is simply for doing resume stuff and not for managing specific things that happened that triggered the resume event, which is totally cool.
It's just the way it was mentioned in the docs made sense for the order that things appear to happen when you close the menu.
Documentation change is better than screwing over other Devs that may be relying on the current behaviour for sure.
I just wanted to say that I'm having more fun programming for the Playdate in C than I've had in almost a decade of game programming and can't wait to get my Playdate and release something!
