thomas.friedrichsmeier at ruhr-uni-bochum.de
Wed May 16 19:08:02 UTC 2018
On Wed, 16 May 2018 17:12:58 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> Am Mittwoch, 9. Mai 2018, 09:15:00 CEST schrieb Thomas
> > In fact, I'm wondering whether it would make sense - or more
> > precisely whether it would be worth the trouble - to adjust
> > rk.show.question() itself to NA as return value for "Cancel". (For
> > better drop-in compatibility with askYesNo(), but, admittedly NA
> > seems a better choice than NULL, here).
> > Of course for backwards compatibility, that would mean adding a new
> > function with that return value (say rk.ask.question()), deprecating
> > rk.show.question(), and removing it in the future...
> that's an even better idea. i've pushed something for testing, i just
> called the new function rk.askYesNo() and modelled its arguments
> after askYesNo().
> please check it out!
nice! Seems to work just fine. So with this, we can just do
options("askYesNo"=rk.askYesNo), and that's it, right?
I suppose we may want to add a "..." parameter in front of caption,
just to be on the safe side, in case askYesNo() gains further parameters
in the future. Although, not sure, how R would handle that, given that
"askYesNo" is a documented option.
Could you also document the return value, explicitly, and mention that
buttons can be hidden by supplying "" as their label?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the rkward-devel