Typically, UIs wait for a user to manipulate a control, and then respond to each user action in turn. Each control, and the UI itself, has one or more callbacks, named for the fact that they "call back" to MATLAB® to ask it to do things. A particular user action, such as pressing a screen button, or passing the cursor over a component, triggers the execution of each callback. The UI then responds to these events. You, as the UI creator, write callbacks that define what the components do to handle events.
This kind of programming is often referred to as event-driven programming. In event-driven programming, callback execution is asynchronous, that is, events external to the software trigger callback execution. In the case of MATLAB UIs, most events are user interactions with the UI, but the UI can respond to other kinds of events as well, for example, the creation of a file or connecting a device to the computer.
You can code callbacks in two distinct ways:
As MATLAB language functions stored in files
As strings containing MATLAB expressions or commands
'c = sqrt(a*a + b*b);'or
Using functions stored in code files as callbacks is preferable to using strings, because functions have access to arguments and are more powerful and flexible. You cannot use MATLAB scripts (sequences of statements stored in code files that do not define functions) as callbacks.
Although you can provide a callback with certain data and make it do anything you want, you cannot control when callbacks execute. That is, when your UI is being used, you have no control over the sequence of events that trigger particular callbacks or what other callbacks might still be running at those times. This distinguishes event-driven programming from other types of control flow, for example, processing sequential data files.