% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/update-input.R
\name{updateRadioButtons}
\alias{updateRadioButtons}
\title{Change the value of a radio input on the client}
\usage{
updateRadioButtons(session, inputId, label = NULL, choices = NULL,
  selected = NULL, inline = FALSE, choiceNames = NULL,
  choiceValues = NULL)
}
\arguments{
\item{session}{The \code{session} object passed to function given to
\code{shinyServer}.}

\item{inputId}{The id of the input object.}

\item{label}{The label to set for the input object.}

\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. 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{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{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
}
\details{
The input updater functions send a message to the client, telling it to
change the settings of an input object. The messages are collected and sent
after all the observers (including outputs) have finished running.

The syntax of these functions is similar to the functions that created the
inputs in the first place. For example, \code{\link{numericInput}()} and
\code{updateNumericInput()} take a similar set of arguments.

Any arguments with NULL values will be ignored; they will not result in any
changes to the input object on the client.

For \code{\link{radioButtons}()}, \code{\link{checkboxGroupInput}()} and
\code{\link{selectInput}()}, the set of choices can be cleared by using
\code{choices=character(0)}. Similarly, for these inputs, the selected item
can be cleared by using \code{selected=character(0)}.
}
\examples{
## Only run examples in interactive R sessions
if (interactive()) {

ui <- fluidPage(
  p("The first radio button group controls the second"),
  radioButtons("inRadioButtons", "Input radio buttons",
    c("Item A", "Item B", "Item C")),
  radioButtons("inRadioButtons2", "Input radio buttons 2",
    c("Item A", "Item B", "Item C"))
)

server <- function(input, output, session) {
  observe({
    x <- input$inRadioButtons

    # Can also set the label and select items
    updateRadioButtons(session, "inRadioButtons2",
      label = paste("radioButtons label", x),
      choices = x,
      selected = x
    )
  })
}

shinyApp(ui, server)
}
}
\seealso{
\code{\link{radioButtons}}
}
