askYesNo()

[Thomas Friedrichsmeier]

Hi,

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
> Friedrichsmeier:
> > 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?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20180516/8529e3a5/attachment.sig>