This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
component:signals [2016/05/25 20:51] xarses update to match actual fields returned |
component:signals [2017/11/13 01:20] jv110 A few typos under screen_resized, add sneak-activating note under touch |
||
---|---|---|---|
Line 40: | Line 40: | ||
- `screen_resized(screenAddress: string, newWidth: number, newHeight: number)` | - `screen_resized(screenAddress: string, newWidth: number, newHeight: number)` | ||
- | This signal is queued by [[block:screen|screen]] when their resolution changes, for example because it is manually set via the [[component:gpu|GPU]]. The address is the address of the screen the queued the signal. | + | This signal is queued by [[block:screen|screens]] when their resolution changes, for example because it was manually set via a [[component:gpu|GPU]]. The address is the address of the screen that queued the signal. |
- `touch(screenAddress: string, x: number, y: number, button: number, playerName: string)` | - `touch(screenAddress: string, x: number, y: number, button: number, playerName: string)` | ||
- | This signal is queued by screens of tier two and tier three when they are clicked. This includes left clicks in the GUI (i.e. when a keyboard is attached) or when right-clicking/activating them in the world directly (i.e. when no keyboard is attached). The address is the address of the screen the queued the signal. The x and y coordinates are in "letters" (meaning they map directly to `term.setCursor` or `gpu.set`, for example). The player name is the user name of the player that triggered the event. | + | This signal is queued by screens of tier two and tier three when they are clicked. This includes left clicks in the GUI (i.e. when a keyboard is attached) or when right-clicking/activating them in the world directly (i.e. when no keyboard is attached or when sneak-activating). The address is the address of the screen the queued the signal. The x and y coordinates are in "letters" (meaning they map directly to `term.setCursor` or `gpu.set`, for example). The player name is the user name of the player that triggered the event. |
Note on the player name: I'll probably add an option to disable this argument in the future, for those who think it's too... unrealistic. It's just quite handy for multi-user programs, so I left it in for now. | Note on the player name: I'll probably add an option to disable this argument in the future, for those who think it's too... unrealistic. It's just quite handy for multi-user programs, so I left it in for now. | ||
//Important//: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[:computer_users|registered as a user]] on the computer (or there are no users registered on the computer). | //Important//: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[:computer_users|registered as a user]] on the computer (or there are no users registered on the computer). | ||
Line 48: | Line 48: | ||
This signal is almost equivalent to the `touch` signal. The only difference is the implicit meaning: when this signal is fired, it "belongs" to a `touch` signal that was fired earlier. This can only be triggered by dragging in the GUI. | This signal is almost equivalent to the `touch` signal. The only difference is the implicit meaning: when this signal is fired, it "belongs" to a `touch` signal that was fired earlier. This can only be triggered by dragging in the GUI. | ||
- `drop(screenAddress: string, x: number, y: number, button: number, playerName: string)` | - `drop(screenAddress: string, x: number, y: number, button: number, playerName: string)` | ||
- | This signal is only triggered if a `drag` event was triggered first. It is fired when the player releases the mouse button, so it's basically a conditional mouse-up event (with the condition being that the mouse moved while the button was held). | + | This signal is triggered when the player releases the mouse button after a `touch` signal. Despite the name, it does not necessarily follow a `drag` signal. |
- `scroll(screenAddress: string, x: number, y: number, direction: number, playerName: string)` | - `scroll(screenAddress: string, x: number, y: number, direction: number, playerName: string)` | ||
This signal is queued by screens of tier two and tier three when the player uses the mouse wheel in the GUI. The x and y coordinates are the cursor location when the scroll occurred and are, like the `touch` signal, in "letters". The `direction` indicates which way to scroll, where a positive value usually means "up", whereas a negative value means "down". Note that this may differ based on the client's operating system and/or driver configuration. The player name is the user name of the player that triggered the event. | This signal is queued by screens of tier two and tier three when the player uses the mouse wheel in the GUI. The x and y coordinates are the cursor location when the scroll occurred and are, like the `touch` signal, in "letters". The `direction` indicates which way to scroll, where a positive value usually means "up", whereas a negative value means "down". Note that this may differ based on the client's operating system and/or driver configuration. The player name is the user name of the player that triggered the event. |