Would it help to add a function like
fl_message_window_closed() that would return 1 if the last dialog (fl_ask, fl_choice, etc.) was closed w/o pressing a button (or using its shortcut), i.e. by Escape or the window close button? User code would then look like:
int ret = fl_choice(...);
if ( /* ret == 0 && */ fl_message_window_closed())
ret = -1;
You could put that in your own
fl_choice() wrapper or use it whenever you need it. I don't think you need the "
ret == 0 &&" part but I added it above for clarity.
I also thought about making it possible to assign a callback for [ the next call of ] a standard dialog which would get the window close event (by Escape or window close button) but that seems to be more complicated (a) for the user to set up and (b) for the internal implementation. Or maybe not.
Thoughts, other ideas?
PS: In the future I'd like to get away from these static dialog windows and functions. We need a proper dialog class that can be called by the user or conveniency functions like fl_choice() etc. and can have multiple instances at a time . This new dialog class could take care of this. But that's not yet available.
 Multiple instances can be necessary if such a dialog is triggered by a timeout while another dialog is still open. See also STR 3242: Re-enable nested (aka "recursive") common dialogs. The title is somewhat misleading, it's more about parallel than nested dialogs.
[ Direct Link to Message ]
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.