This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
component:signals [2017/11/13 01:20] jv110 A few typos under screen_resized, add sneak-activating note under touch |
component:signals [2017/12/19 01:18] payonel |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| Signals are messages sent to a computer from some external source and can be used for many purposes. They always have at least a name, and may have any number of (simple) parameters. Note that computers may also queue signals on themselves. | Signals are messages sent to a computer from some external source and can be used for many purposes. They always have at least a name, and may have any number of (simple) parameters. Note that computers may also queue signals on themselves. | ||
| - | Signals can be consumed using [[api:computer|computer.pullSignal()]] or its preferred wrapper, [[api:event|event.pull()]]. The latter is preferred because unwanted signals and the requested signal itself are also distributed as events, which is used by a couple of system functions, such as primary component tracking. | + | Signals can be consumed using [[api:computer|computer.pullSignal()]] or its convenience wrapper, [[api:event|event.pull()]]. |
| The following lists all signals triggered by components and the built-in libraries. They are listed in the following format: `name(arg: type, ...)`, meaning you would pull them like `local name, arg, ... = event.pull()`. For example, to pull a modem message: | The following lists all signals triggered by components and the built-in libraries. They are listed in the following format: `name(arg: type, ...)`, meaning you would pull them like `local name, arg, ... = event.pull()`. For example, to pull a modem message: | ||