Clarify that choices must be strings

R/input-checkboxgroup.R

@@ -8,7 +8,8 @@
 #' @param choices List of values to show checkboxes for. If elements of the list
 #'   are named then that name rather than the value is displayed to the user. If
 #'   this argument is provided, then \code{choiceNames} and \code{choiceValues}
-#'   must not be provided, and vice-versa.
+#'   must not be provided, and vice-versa. The values should be strings; other
+#'   types (such as logicals and numbers) will be coerced to strings.
 #' @param selected The values that should be initially selected, if any.
 #' @param inline If \code{TRUE}, render the choices inline (i.e. horizontally)
 #' @param choiceNames,choiceValues List of names and values, respectively,

R/input-radiobuttons.R

@@ -3,30 +3,30 @@
 #' Create a set of radio buttons used to select an item from a list.
 #'
 #' If you need to represent a "None selected" state, it's possible to default
-#' the radio buttons to have no options selected by using
-#' \code{selected = character(0)}. However, this is not recommended, as it gives
-#' the user no way to return to that state once they've made a selection.
-#' Instead, consider having the first of your choices be \code{c("None selected"
-#' = "")}.
+#' the radio buttons to have no options selected by using \code{selected =
+#' character(0)}. However, this is not recommended, as it gives the user no way
+#' to return to that state once they've made a selection. Instead, consider
+#' having the first of your choices be \code{c("None selected" = "")}.
 #'
 #' @inheritParams textInput
 #' @param choices List of values to select from (if elements of the list are
 #'   named then that name rather than the value is displayed to the user). If
 #'   this argument is provided, then \code{choiceNames} and \code{choiceValues}
-#'   must not be provided, and vice-versa.
-#' @param selected The initially selected value (if not specified then
-#'   defaults to the first value)
+#'   must not be provided, and vice-versa. The values should be strings; other
+#'   types (such as logicals and numbers) will be coerced to strings.
+#' @param selected The initially selected value (if not specified then defaults
+#'   to the first value)
 #' @param inline If \code{TRUE}, render the choices inline (i.e. horizontally)
 #' @return A set of radio buttons that can be added to a UI definition.
-#' @param choiceNames,choiceValues List of names and values, respectively,
-#'   that are displayed to the user in the app and correspond to the each
-#'   choice (for this reason, \code{choiceNames} and \code{choiceValues}
-#'   must have the same length). If either of these arguments is
-#'   provided, then the other \emph{must} be provided and \code{choices}
-#'   \emph{must not} be provided. The advantage of using both of these over
-#'   a named list for \code{choices} is that \code{choiceNames} allows any
-#'   type of UI object to be passed through (tag objects, icons, HTML code,
-#'   ...), instead of just simple text. See Examples.
+#' @param choiceNames,choiceValues List of names and values, respectively, that
+#'   are displayed to the user in the app and correspond to the each choice (for
+#'   this reason, \code{choiceNames} and \code{choiceValues} must have the same
+#'   length). If either of these arguments is provided, then the other
+#'   \emph{must} be provided and \code{choices} \emph{must not} be provided. The
+#'   advantage of using both of these over a named list for \code{choices} is
+#'   that \code{choiceNames} allows any type of UI object to be passed through
+#'   (tag objects, icons, HTML code, ...), instead of just simple text. See
+#'   Examples.
 #'
 #' @family input elements
 #' @seealso \code{\link{updateRadioButtons}}

man/checkboxGroupInput.Rd

@@ -15,7 +15,8 @@ checkboxGroupInput(inputId, label, choices = NULL, selected = NULL,
 \item{choices}{List of values to show checkboxes for. If elements of the list
 are named then that name rather than the value is displayed to the user. If
 this argument is provided, then \code{choiceNames} and \code{choiceValues}
-must not be provided, and vice-versa.}
+must not be provided, and vice-versa. The values should be strings; other
+types (such as logicals and numbers) will be coerced to strings.}
 
 \item{selected}{The values that should be initially selected, if any.}
 

man/radioButtons.Rd

@@ -15,25 +15,26 @@ radioButtons(inputId, label, choices = NULL, selected = NULL,
 \item{choices}{List of values to select from (if elements of the list are
 named then that name rather than the value is displayed to the user). If
 this argument is provided, then \code{choiceNames} and \code{choiceValues}
-must not be provided, and vice-versa.}
+must not be provided, and vice-versa. The values should be strings; other
+types (such as logicals and numbers) will be coerced to strings.}
 
-\item{selected}{The initially selected value (if not specified then
-defaults to the first value)}
+\item{selected}{The initially selected value (if not specified then defaults
+to the first value)}
 
 \item{inline}{If \code{TRUE}, render the choices inline (i.e. horizontally)}
 
 \item{width}{The width of the input, e.g. \code{'400px'}, or \code{'100\%'};
 see \code{\link{validateCssUnit}}.}
 
-\item{choiceNames, choiceValues}{List of names and values, respectively,
-that are displayed to the user in the app and correspond to the each
-choice (for this reason, \code{choiceNames} and \code{choiceValues}
-must have the same length). If either of these arguments is
-provided, then the other \emph{must} be provided and \code{choices}
-\emph{must not} be provided. The advantage of using both of these over
-a named list for \code{choices} is that \code{choiceNames} allows any
-type of UI object to be passed through (tag objects, icons, HTML code,
-...), instead of just simple text. See Examples.}
+\item{choiceNames, choiceValues}{List of names and values, respectively, that
+are displayed to the user in the app and correspond to the each choice (for
+this reason, \code{choiceNames} and \code{choiceValues} must have the same
+length). If either of these arguments is provided, then the other
+\emph{must} be provided and \code{choices} \emph{must not} be provided. The
+advantage of using both of these over a named list for \code{choices} is
+that \code{choiceNames} allows any type of UI object to be passed through
+(tag objects, icons, HTML code, ...), instead of just simple text. See
+Examples.}
 }
 \value{
 A set of radio buttons that can be added to a UI definition.
@@ -43,11 +44,10 @@ Create a set of radio buttons used to select an item from a list.
 }
 \details{
 If you need to represent a "None selected" state, it's possible to default
-the radio buttons to have no options selected by using
-\code{selected = character(0)}. However, this is not recommended, as it gives
-the user no way to return to that state once they've made a selection.
-Instead, consider having the first of your choices be \code{c("None selected"
-= "")}.
+the radio buttons to have no options selected by using \code{selected =
+character(0)}. However, this is not recommended, as it gives the user no way
+to return to that state once they've made a selection. Instead, consider
+having the first of your choices be \code{c("None selected" = "")}.
 }
 \examples{
 ## Only run examples in interactive R sessions

man/updateCheckboxGroupInput.Rd

@@ -19,7 +19,8 @@ updateCheckboxGroupInput(session, inputId, label = NULL, choices = NULL,
 \item{choices}{List of values to show checkboxes for. If elements of the list
 are named then that name rather than the value is displayed to the user. If
 this argument is provided, then \code{choiceNames} and \code{choiceValues}
-must not be provided, and vice-versa.}
+must not be provided, and vice-versa. The values should be strings; other
+types (such as logicals and numbers) will be coerced to strings.}
 
 \item{selected}{The values that should be initially selected, if any.}
 

man/updateRadioButtons.Rd

@@ -19,32 +19,33 @@ updateRadioButtons(session, inputId, label = NULL, choices = NULL,
 \item{choices}{List of values to select from (if elements of the list are
 named then that name rather than the value is displayed to the user). If
 this argument is provided, then \code{choiceNames} and \code{choiceValues}
-must not be provided, and vice-versa.}
+must not be provided, and vice-versa. The values should be strings; other
+types (such as logicals and numbers) will be coerced to strings.}
 
-\item{selected}{The initially selected value (if not specified then
-defaults to the first value)}
+\item{selected}{The initially selected value (if not specified then defaults
+to the first value)}
 
 \item{inline}{If \code{TRUE}, render the choices inline (i.e. horizontally)}
 
-\item{choiceNames}{List of names and values, respectively,
-that are displayed to the user in the app and correspond to the each
-choice (for this reason, \code{choiceNames} and \code{choiceValues}
-must have the same length). If either of these arguments is
-provided, then the other \emph{must} be provided and \code{choices}
-\emph{must not} be provided. The advantage of using both of these over
-a named list for \code{choices} is that \code{choiceNames} allows any
-type of UI object to be passed through (tag objects, icons, HTML code,
-...), instead of just simple text. See Examples.}
+\item{choiceNames}{List of names and values, respectively, that
+are displayed to the user in the app and correspond to the each choice (for
+this reason, \code{choiceNames} and \code{choiceValues} must have the same
+length). If either of these arguments is provided, then the other
+\emph{must} be provided and \code{choices} \emph{must not} be provided. The
+advantage of using both of these over a named list for \code{choices} is
+that \code{choiceNames} allows any type of UI object to be passed through
+(tag objects, icons, HTML code, ...), instead of just simple text. See
+Examples.}
 
-\item{choiceValues}{List of names and values, respectively,
-that are displayed to the user in the app and correspond to the each
-choice (for this reason, \code{choiceNames} and \code{choiceValues}
-must have the same length). If either of these arguments is
-provided, then the other \emph{must} be provided and \code{choices}
-\emph{must not} be provided. The advantage of using both of these over
-a named list for \code{choices} is that \code{choiceNames} allows any
-type of UI object to be passed through (tag objects, icons, HTML code,
-...), instead of just simple text. See Examples.}
+\item{choiceValues}{List of names and values, respectively, that
+are displayed to the user in the app and correspond to the each choice (for
+this reason, \code{choiceNames} and \code{choiceValues} must have the same
+length). If either of these arguments is provided, then the other
+\emph{must} be provided and \code{choices} \emph{must not} be provided. The
+advantage of using both of these over a named list for \code{choices} is
+that \code{choiceNames} allows any type of UI object to be passed through
+(tag objects, icons, HTML code, ...), instead of just simple text. See
+Examples.}
 }
 \description{
 Change the value of a radio input on the client