Platforms to show: All Mac Windows Linux Cross-Platform
Back to CarbonSystemEventsMBS class.
CarbonSystemEventsMBS.DisplayReconfigured
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 9.2 | ✅ Yes | ❌ No | ❌ No | ❌ No |
This event is sent to all handlers registered for it on the application event target. When this event is received, applications may wish to update geometry and color depth usage or perform a redraw based on the new configuration.
Sent in Mac OS X 10.5 and newer.
CarbonSystemEventsMBS.DisplaysAsleep
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 9.2 | ✅ Yes | ❌ No | ❌ No | ❌ No |
Sent in Mac OS X 10.4 and newer.
CarbonSystemEventsMBS.DisplaysAwake
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 9.2 | ✅ Yes | ❌ No | ❌ No | ❌ No |
Sent in Mac OS X 10.4 and newer.
CarbonSystemEventsMBS.TimeDateChanged
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 4.0 | ✅ Yes | ❌ No | ❌ No | ❌ No |
Requires Mac OS X 10.3 or newer.
The RB date class may not recognize the case when just the time zone changed.
Some examples using this event:
CarbonSystemEventsMBS.UserSessionActivated
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 4.0 | ✅ Yes | ❌ No | ❌ No | ❌ No |
Requires Mac OS X 10.3 or newer.
From Apple's documentation:
When a user switch occurs, Mac OS X generates events for all interested applications. Events are sent to applications in a login session whenever the login session is activated or deactivated. If a login session is not being activated or deactivated, it receives no events. You can use the activation events to perform the following kinds of tasks:
- Halt or restart sound playback
- Halt or restart animations
- Give up or acquire shared resources
- Put your application into a quiescent state to improve overall system performance
Event Timing
User switch notifications are sent to applications at the same time the switch occurs. Because the switch occurs relatively quickly, this is normally not a problem. However, it is possible for an application to receive its activation event before other applications have received their deactivation events. This could lead to potential race conditions between applications releasing and acquiring shared resources.
To avoid race conditions, applications in the session being deactivated should continue to release any shared resources as soon as possible. Applications in the session being activated should delay the acquisition of any shared resources until those resources are actually used. Not only can this help avoid potential race conditions, it can also improve overall system performance. If your application needs a particular resource right away but encounters errors while trying to acquire it, set a timer and try to acquire the resource again a short time later.
Some examples using this event:
CarbonSystemEventsMBS.UserSessionDeactivated
| Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
| event | Carbon Events | MBS MacCF Plugin | 4.0 | ✅ Yes | ❌ No | ❌ No | ❌ No |
Requires Mac OS X 10.3 or newer.
From Apple's documentation:
When a user switch occurs, Mac OS X generates events for all interested applications. Events are sent to applications in a login session whenever the login session is activated or deactivated. If a login session is not being activated or deactivated, it receives no events. You can use the activation events to perform the following kinds of tasks:
- Halt or restart sound playback
- Halt or restart animations
- Give up or acquire shared resources
- Put your application into a quiescent state to improve overall system performance
Event Timing
User switch notifications are sent to applications at the same time the switch occurs. Because the switch occurs relatively quickly, this is normally not a problem. However, it is possible for an application to receive its activation event before other applications have received their deactivation events. This could lead to potential race conditions between applications releasing and acquiring shared resources.
To avoid race conditions, applications in the session being deactivated should continue to release any shared resources as soon as possible. Applications in the session being activated should delay the acquisition of any shared resources until those resources are actually used. Not only can this help avoid potential race conditions, it can also improve overall system performance. If your application needs a particular resource right away but encounters errors while trying to acquire it, set a timer and try to acquire the resource again a short time later.
Some examples using this event:
The items on this page are in the following plugins: MBS MacCF Plugin.
