How Windows Work

This section covers the basic appearance and behavior of all OpenStep windows--standard windows, panels, menus, pop-up and pull-down lists, miniwindows, and application icons.

---

Note - The window behavior described in this section is automatically handled by the Application Kit's NSWindow class and its subclasses. The application-specific behavior you design and implement is covered in "Implementing Windows" later in this chapter.

---

Parts of a Window

The parts of a window are illustrated in Figure 4-2.

Figure 4-2

Every window has a content area where the application can be used to enter text and images.

Standard windows, panels, and menus also have title bars above their content areas and borders that surround both content area and title bar. The title bar is the user's control center for one of these windows. The title bar displays the window's title, if it has one, and often contains buttons the user can click on to dismiss it from the screen. In addition, the user moves the window by dragging its title bar.

Panels and standard windows can also have resize bars, which appear at the bottom of a window, below the content area but within the border. By dragging any of the regions of the resize bar, users can alter the sizes and shapes of the windows on their screens. The resize bar is the only window control outside the title bar.

Window Order

As users work, they move windows around and move from window to window. This freedom is essential, but it does allow them to put larger windows over smaller ones. If there were no restrictions on window ordering, users could cover their menus and docked icons with standard windows and even lose sight of attention panels and pop-up lists that required immediate attention.

To prevent problems of this sort, which would certainly confuse users, the different types of windows (menus, panels, standard windows, and so on) are assigned to different levels. A window is only allowed to cover windows in lower levels. There are seven levels:

• Windows that appear in a spring-loaded mode--pop-up lists, pull-down lists, and menus opened with the mouse's Menu button--are assigned to the frontmost, or first, level. These windows remain on screen only while the user holds the mouse button down, and so they only momentarily obscure other windows. Putting them in the first level guarantees that they will not come up behind other windows.
• Attention panels are assigned to the second level. Like spring-loaded windows, they are on screen temporarily. But unlike spring-loaded windows, which disappear when the user releases the mouse button, attention panels must be explicitly dismissed. They are assigned to the second level, so they cannot be covered by other windows. This keeps them in front of the user until they are dismissed, thus encouraging prompt user responses.
• The main menu is assigned to the third level. Unless some user action has opened a spring-loaded window or an attention panel, the main menu is the frontmost window on the screen.
• Other menus are assigned to the fourth level, just below the main menu. They can cover each other, but not the main menu.
• Docked application icons occupy the fifth level. They can be covered by spring-loaded windows, attention panels, and menus, but not by the ordinary windows of your application.

• Floating panels are in the sixth level. Floating panels are defined and discussed in Chapter 5, "Panels."
• All other windows are grouped in the seventh level. This is the largest level, and it holds most of the windows on the screen. These windows can cover each other, but cannot come in front of spring-loaded windows, attention panels, menus, the dock, or floating panels.

This seven-level system keeps windows in the upper levels in view and readily available to the user; it prevents them from being inadvertently lost in a large pile of windows. Although attention panels, menus, and docked application icons can cover other windows, the user can get them out of the way when necessary: attention panels can be attended to and dismissed, menus can be moved to the side or closed, and the dock can be slid mostly off screen.

Some other points worth noting are listed below:

• When a window is first placed on screen, it comes up at the front of its level to get the user's attention.
• When two windows belong to the same level, either one can be in front. When two windows belong to different levels, however, the one in the higher level will always be above the other.
• Every window has its own position in the order; even when two windows appear to by side-by-side, one is technically in front of the other.
• Even when a window is covered by other windows, it is considered to be on screen; it retains its ranking in the order and can be exposed by moving the windows above it to the side.
• Application and window status (which is the currently active application and which is the current key window) also play a part in determining the order in which the windows are displayed. See "Application and Window Status" later in this chapter for more information.

Window Characteristics

This section describes basic window characteristics. Notice that some of these behaviors are implemented by including optional parts (see Figure 4-2) in a particular window; you can modify the behavior of windows you create by adding or removing these parts:

• Reordering -- Any window can be brought to the front of its level. Notice that it can only be brought to the front of its own level, which prevents users from moving a standard window in front of an attention panel or a menu.
• Moving -- Any window with a title bar can be moved to a new location on the screen, as can any miniwindow or application icon.
• Resizing --.Any window with a resize bar can be resized.
• Closing and miniaturizing -- A window with the appropriate buttons in its title bar can be closed or miniaturized.
• Hiding and Retrieving -- The Hide menu command lets users hide windows so they are not visible on the screen. This is not the same as closing them.

Reordering

Clicking on a window brings it to the front of its level, unless the click is on a title bar button. The window is reordered immediately when the mouse button is pressed. If the user is dragging the window to a new location, the window moves to the top of its level before it is moved.

Another way the user can reorder windows is to hold the Command key and press either the up-arrow or down-arrow. Command-up Arrow moves the backmost window (if it is in the lowest level) or standard window to the front of the level. Command-down Arrow moves the frontmost window to the back.

Moving

The user can drag any window by its title bar (if it has one). To drag a window, users must press and release the mouse button. This counts as a click and brings the window to the front of its level.

Resizing

Figure 4-3

If a window has a resize bar, users can change its size by dragging the resize bar. While the bar is being dragged, an outline of the window's border follows the pointer, as shown in Figure 4-3. When the user releases the mouse button, the window is resized to the outline.

Closing and Miniaturizing

A window's title bar can display two buttons, which are shown in Figure 4-4:

Figure 4-4

The window in front has both buttons as they normally appear. The miniaturize button is on the left, and the close button is on the right. The window in back shows a broken close button, which indicates that the window is displaying a document that the user has edited but not saved. "Implementing Windows" later in this chapter has more information on the miniaturize and close buttons.

The user clicks the buttons either to miniaturize or close the window, as described in Table 4-1. The click does not bring the window to the front, make it the key window, or activate an application. (The key window and the active application are discussed in "Application and Window Status" later in this chapter.)

Table 4-1

Button	What It Does
Miniaturize button	Replaces the window with a miniwindow. The miniwindow represents the window on screen and gives the user access to it. Double-clicking the miniwindow causes it to disappear and the window that was miniaturized to reappear.
Close button	Closes the document displayed in the window, and removes the window from the screen.

Miniaturizing Miniaturizing a window clears it from the screen without destroying it or changing its contents. From the user's point of view, the window is transformed into a miniwindow. Double-clicking the miniwindow reverses the miniaturization.

Most standard windows and some panels have a miniaturize button. They can be miniaturized using either the button or the standard Miniaturize Window menu command. A group of windows representing a single document can be miniaturized into a single miniwindow, as described in "Document Menu" in Chapter 6.

Users cannot work in a miniaturized window, but programs can continue to update the window's display. If you begin compiling a program in a Terminal window and then miniaturize the window, the compiler messages will be visible when you unminiaturize the window.

Miniaturizing differs from closing in a number of ways:

• Miniaturizing preserves the window as it was last seen on screen. A window that is closed cannot necessarily be brought up in the same state.
• Miniaturizing a window leaves a miniwindow behind so that it can be brought back up on the screen. Closing a window does not provide the user with a way to do this.
• Miniaturizing a window that displays a file will not the file or change the way it is displayed. Closing a window usually closes the file it displays.

Closing The close button removes a window from the screen. What this means depends on the type of window:

Table 4-2

Type of Window	Effect of Closing the Window
Menus and panels	A menu that is closed is removed from the screen, but the user retains a way to reopen it quickly with a command in another menu. Panels that are closed can be reopened in the same way. (See Chapter 6, "Menus," for more information on menus.) When a panel that was closed is reopened, it assumes its former size and location and retains its former state. From the user's point of view (and programmatically) it is the same panel that was closed.
Standard windows	Closing a standard window usually removes it from the application as well as from the screen. From the user's point of view, the same window cannot necessarily be brought up again. The selection in effect when the window was closed might not be preserved, and the new window will not necessarily be located in the same place or have the same dimensions as the old one, especially when the user moved or resized the window before closing it.

Hiding and Retrieving Windows

The Hide menu command lets the user clear the screen of all the windows that belong to one application. This clears the workspace and makes it easier to work in another application.

When an application is hidden-only its application icon remains on the screen. When the user double-clicks the icon, the hidden windows reappear, arranged as they were before being hidden. Users can resume working in the application, picking up again at exactly the point where they left off.

Double-clicking the icon has one other effect: it activates the application (as discussed in the next section), which may cause the menus and panels of another application to disappear while those of the newly activated application reappear.

Double-clicking the icon for a running application activates it and brings its windows to the front, even if the application was not hidden. (The user can also bring covered windows forward using commands in the Windows menu, as described in Chapter 6, "Menus.") The application's menus also return to the screen.

If the user holds down the Command key while double-clicking an application icon, the application is activated as usual, but in addition all other applications are hidden.

Notice that when a window is completely obscured by other windows, it is covered by them but not hidden in the sense used here. Users can make a covered window visible by moving the windows above it to the side. This will not work for a hidden window, which is completely removed from the workspace.

Application and Window Status

Since more than one application can run at a time in OpenStep, the screen is likely to display windows for several applications. Users must be able to pick the application and window they want to work in. There are three OpenStep concepts that help them do this:

• The application that the user is currently working in is known as the active application.
• The windows that are the current focus of user attention in the active application are known as the key window and the main window. These are usually one and the same.

The terms key window and main window describe functional roles. Both roles can be assumed by the same window, or each can be assumed by a different window:

• The key window is the window that receives characters from the keyboard.
• The main window is the window containing the selected target for controls.

Keep in mind that the active application, the key window, and the main window, are not fixed properties of specific applications and windows, but concepts that describe an application's or a window's status at a particular point in time. The status will change as the user works with the computer, and OpenStep provides feedback to indicate where the active application, key window, and main window are. This is discussed more fully in the three sections that follow.

Active Application

From all of the applications running on a computer, the user can select only one to be the active application. The user must activate an application before being allowed to enter text in its windows or use its menus.

The appearance and behavior of the active application are distinguished in the following ways:

• It is the only application with visible menus. When an application is deactivated, its menus are hidden from view. When it is reactivated, they are restored to the screen.
• It is the application that owns most, if not all, of the panels that are visible on the screen. In general, panels behave like menus. They hide when the application is not active and return to the screen when the application is reactivated. (In some situations it is appropriate to implement a panel that remains on screen when the application is not active; see Chapter 5, "Panels," for guidelines.)
• It is the application that receives the user's keyboard actions. Typing and keyboard alternatives can affect only the active application. When there is no active application the user's keystrokes have no effect.
• It is the application that contains the key window and main window (if there is a current key window or main window), and its windows are likely to be in front of the windows of other applications.

Application Activation In general, the task of selecting the active application is left to the user. The user's action can be direct, such as starting up the application or clicking on one of its windows, or indirect, such as having one application send a message to another application.

The only exception to this principle is when the user hides or terminates the active application. In this situation, OpenStep guesses which of the applications with windows on the screen should be activated next, which often saves the user from clicking to choose the new active application.

The actions that activate an application are:

• The user starts it up, unless the user activates another application while the first one is starting up.
• The application owns the panel or standard window that is frontmost on screen after the user hides or terminates the current application.
• The user double-clicks a miniwindow belonging to the application, or double-clicks the application's freestanding or docked icon. Double-clicking a docked icon starts up the application if it is not already running.
• The user clicks on one of the windows that belong to the application, provided the window is not a miniwindow or application icon.
• The application receives a message from another application that asks it to do some work requiring interaction with the user. Receiving a message from the Workspace Manager that asks the receiving application to open a file is one example. See "Activating an Application" later in this chapter for details.

Application Deactivation There can be only one active application per workspace (that is, one per Window Server) at a time. Whenever the user chooses a new active application, the currently active application is automatically deactivated. The Application Kit and Workspace Manager take care of this task.

The active application is also deactivated when:

• The user hides its windows (by using the Hide command).
• The user terminates it (by choosing the Quit command).

In either case, if there are other applications with panels or standard windows on the screen, then the Workspace Manager activates the application that owns the frontmost panel or window. If no other application has panels or a standard window on screen, no application becomes active.

In addition, an application that sends a message to another application with intention of activating the other application should deactivate itself just before sending the message. See "Activating an Application" later in this chapter for details.

---

Note - A deactivated but running application can still do work. It is deactivated only in the sense that the user cannot interact with it without reactivating it.

---

Key Window

Users expect to see their actions on the keyboard and mouse applied to a specific window in a specific application. They need to know which window will be affected before they act--there should be no surprises.

Because the user is controlling the pointer location with the mouse, the user can place the pointer over a window and know that the next mouse action will affect that window. The window where typing will appear must also be obvious to users, so OpenStep visually identifies the key window (the window where typing will appear).

To identify the key window for users, the App Kit highlights its title bar by turning it black. This is illustrated in Figure 4-5.

Figure 4-5

You can think of the title bar highlighting as a pointer for the keyboard. It moves from window to window as the key window changes. Key-window status also moves from application to application as the active application changes. Only one window on the screen has the highlighted title bar, and it must belong to the active application. There is just one key window per computer. Even a system that has two screens, but only one keyboard, has at most one key window.

A window does not have to become the key window to receive, and act on, keyboard alternatives. It must, however, belong to the active application.

Since the key window belongs to the active application, its black title bar has the secondary effect of helping to show which application is currently active. The key window is the most prominently marked window in the active application, making it key in a second sense: it is the main focus of the user's attention on the screen.

Main Window

The main window is the standard window where the user is currently working. It is the ultimate focus of any user action carried out with a menu or panel. When a user opens the Find panel, for example, it becomes the key window because the user must type in criteria for the Find operation. But the panel is

just an instrument with which the user is working on a document displayed in another window. That other window, the one displaying the document, is known as the main window.

Whenever a standard window becomes the key window, it also becomes the main window. When the key window status moves from a standard window to a panel, the standard window retains main window status.

Figure 4-6

To identify the main window in situations when the main and key windows are different, the Application Kit highlights the main window's title bar in dark gray. (When the main window is also the key window, it has only the black highlighting that indicates key window status.) Figure 4-6 illustrates highlighting the main window when it is also the key window. Figure 4-7 illustrates highlighting when the main window is not the key window.

Figure 4-7

A menu command can operate on either the key window or the main window, depending on the nature of the command. For example, the Paste command can be used to enter text in a Find panel when it is the key window. But the Save command will always save the document displayed in the main window, and the Bold command will make the current selection in the main window boldface. The rules for this behavior are:

• The action called for by a command is first directed to the key window. If the key window can handle the action, it does.
• If the key window is a panel and cannot handle the action, the action is next directed to the main window.

Note that this order of precedence is reflected in the way windows are highlighted: the key window is always highlighted, but the main window is highlighted only when it is not the key window.

The main window and key window are always in the active application. The main window follows the key window, as user actions shift the focus from window to window and from application to application.

How Windows Become the Key Window or Main Window

In most situations the user, rather than the application, selects the key window and main window. This section describes how different user actions select a main or key window and the part that the App Kit plays. Those few situations in which your application needs to choose its own key window are covered in "Choosing the Key Window" later in this chapter.

In the Currently Active Application The user designates a new key window by clicking on any of the windows displayed by the active application. If the new key window is a standard window, it also gets main window status. If the new key window is a panel that accepts text entry, it gets key window status, but the original main window retains main window status and gets main window highlighting (a dark gray title bar). Notice that the user cannot select a main window without also making it the key window.

When the user closes or miniaturizes the window that has key window status, the App Kit chooses a new key window (or main window) for the active application. When the user closes the last open window, so that the application has no more windows on screen, no new key window can be chosen, although the application still remains active.

When an Application Is Activated When an application is activated, one of its windows gets key window status and one (usually the same one) gets main window status. Whenever possible, status is assigned as a result of user action:

• If the user activates the application by clicking on a window that accepts keystrokes, that window gets key window status. If it is a standard window, it also gets main window status.
• If the user activates the application by double-clicking on a miniwindow, the miniaturized window is brought up on screen and gets both key window and main window status.

If the action that activates the application does not directly select a new key window, each window retains it previous status. If the user reactivates an application by double-clicking its icon, the windows that had key and main window status when the application was deactivated retain their status.

---

Note - When an application is activated, its key window may be highlighted before the newly deactivated application's key window loses its key window highlighting. This is an aspect of OpenStep's multitasking environment, in which users can begin working in one process (the new active application) before their instructions to another process (the previously active application) have been completed. Although the deactivated application's key window may retain its highlighting for a short time, it is not the key window--all keyboard actions are directed to the newly activated application.

---

Results of Clicking on a Window

Clicking on a window has two separate, but related, results:

• The window usually becomes the key window (and in most situations the main window), and the application that owns it is activated. Standard windows always get key window status when clicked, but panels might not. This is covered in detail in Chapter 5, "Panels."
• The window comes to the front of its level.

The first is a change in the window's status, the second in its position on screen. Both must happen before the user can work in the window. Moving it in front of other windows makes its contents available; making it the key window allows the user to type in it and give it menu commands.

In the OpenStep interface, these two results of a mouse click, while logically related, can take place separately. If the user Alt-clicks on the window's title bar, the actions will bring the window to the front without making it the key window or activating its application. Alt-clicking on title bars thus lets users rearrange and reorder windows on the screen without changing window or application status.

Implementing Windows

This section covers guidelines for designing and placing the different types of windows used in your application.

Designing Windows

The only windows that have a fixed size are miniwindows and icons. The initial sizes of all other windows are determined by the application developer. Standard windows are usually larger than panels, and panels are usually larger than menus, but there are no absolute rules.

When designing a panel or standard window, you should keep a substantial part of it free of objects that will respond to the user's first click. Make it easy for your users to find a place to click within the window and select it.

Try to limit the number of panels and standard windows your users need to bring up in order to use the application. Too many windows result in a cluttered screen that might confuse users. Even two windows will be excessive if users cannot tell which one they are supposed to work in. Finally, if your application clutters the screen, it will be difficult for your users to work in more than one application.

Placing Windows

One of the basic principles of the OpenStep user interface is that users control their own workspaces. One aspect of this control is the freedom to rearrange windows to suit their own tastes and needs. To maintain user window arrangements, window that are dismissed and brought up again must reappear in their previous locations.

To avoid making the user rearrange windows unnecessarily, each of your panels and nondocument standard windows should remember its own location when it is dismissed. The next time the window is brought up, it should reappear in the same location. Suppose, for example, the user brings up a Find panel, moves it to a new position, and then closes it. The next time the user brings up the panel, it should come up in its user-defined position, even when the user has quit and restarted the application.

Whether your document windows should also remember their position depends on the nature of the application. For example, Mail message windows do not remember their positions because users typically open many documents at once, and thus need the application's help in positioning the windows. However, an application such as a drawing program that is typically used for editing one file at a time should probably let the user determine each document window's default location.

The first time a window comes up, its position is determined by the application. To ensure a consistent user interface, all applications should follow these guidelines for initial locations of windows:

• When an application starts up, its main menu should appear in the upper left corner of the screen, unless the user has specified a different location for it.
• Standard windows should come up to the right of the main menu, allowing enough room for submenus that might later be attached to the main menu. Some applications also allow room for panels to come up to the left of the standard window and below the main menu.
• Attention panels should come up centered in the upper part of the screen, where they cannot be overlooked.
• No part of any window (other than miniwindows and icons) should be placed off screen unless the user has put it there.

---

Programmer's Note - There are three methods you can use to help panels and non-document standard windows remember their window position. Calling the setFrameAutosaveName: method once per window makes the window save its position in the defaults system whenever necessary. The next time the window comes up, it appears at the last-saved position. A less automated way of handling the window position is to call saveFrameUsingName: every time you wish to save the position, and call setFrameUsingName: to set the window's position when it is being brought up.

These methods are not appropriate for document windows, since there is no easy way to guarantee unique names for documents. If your application saves the positions of document windows, you should use the saveFrameToString: method to save a representation of the window's position into the document itself. When opening the document, you should position its window using setFrameFromString:.

---

Implementing Standard Windows

The standard window is the most commonly used type of window, and standard windows are used as the principal windows in every application. If an application lets the user edit files, each file should be displayed in a separate standard window. If the application is a game, the game board should be displayed in a standard window, and if the application is a simple accessory like a clock, the clock face should be displayed in a small standard window.

Every standard window has a title bar. Most also have the window controls-- resize bars, close buttons, and miniaturize buttons. This section covers choosing titles for your windows and the user actions you need to implement when your windows have the window controls. It also describes the situations in which it is acceptable to omit the window controls.

Choosing a Title

If a window displays a document that can be saved, the title bar of the window should display the name of the document, an em dash (--) and the path for the folder that contains the document. Use two spaces on each side to set off the em dash. The following example shows the correct title for a window that displays a document named "jobRecords" which is in /net/server/export /records:

jobRecords  --  /net/server/export/records

The title bar is not a good place to show status (such as what the application is currently doing). Status is better displayed in the window's content area or in a panel that accompanies the window. When status is displayed in a window, small, dark gray text is often used (as it is in the Workspace Manager's File Viewer).

---

Programmer's Note - You should use the setTitleWithRepresentedFilename: method of the NSWindow class to set the title of a document window. To produce this window title:

jobRecords  --  /net/server/export/records

you should send the window a setTitleWithRepresentedFilename: message, and the argument to this method should be a pointer to an NSString containing the string /net/server/export/records/jobRecords.

---

Using the Resize Bar

Most standard windows--especially those with scrollable contents--should have a resize bar. The bar gives users control of their environments by letting them determine how much screen space is used for to the contents of the window.

If a window has a resize bar, you should be careful that the window remains useful and legible, no matter how large or small the user makes it. OpenStep lets you constrain a window's dimensions so that it does not become too big or too small too be useful, and you can also restrict it so that it only grows and shrinks by fixed amounts. An example of this is the Workspace Manager File Viewer, which will only grow or shrink by the width of its browser columns, eliminating the possibility of showing only a partial column.

Using the Miniaturize Button

In general, each standard window should have a miniaturize button .

Exceptions to this rule occur when your application has an essential window--the application cannot be used without it. When a window is miniaturized, it should remain miniaturized until the user explicitly unminiaturizes it.

Because a miniaturized window is not likely to be the focus of user attention, applications should not alter the appearance or contents of a miniaturized window without the user's knowledge. They can, however, continue to do work that the user requested before miniaturizing the window. Terminal, for example, will complete any commands that the user entered in a Terminal window before miniaturizing it. Changes that were not initiated by the user before miniaturizing the window are unacceptable. Changing the font used in a miniaturized window, for example, is unacceptable unless the user specifies a font change for all windows.

The Windows menu has a command which is a counterpart to the miniaturize button and miniaturizes the key window. You can also add a command that miniaturizes several related windows into a single miniwindow to the Document menu. See "The Windows Menu" and "The Document Menu" in Chapter 6 for information on these commands.

Using the Close Button

Most standard windows have close buttons . In some situations the close

button is not needed. The Preferences application, for example, has only one standard window, and it cannot be used without that window; so the window has no close button. Compare this to the Edit application, which allows users to open and close multiple documents and also allows them to issue useful commands, such as File/New, when no windows are open.

Your application should break a window's close button whenever it

contains unsaved work. From the user point of view, a broken close button means that the application will not let users lose work by accidentally closing the window without saving the work. If the user tries to close a window with a broken close button or quit the application that owns the window, the application should bring up a Close or Quit panel, which gives the user an opportunity to save the work. (See Chapter 5, "Panels," for more information on these standard panels.)

---

Note - If an application uses multiple windows to display a single file and any one of them contains unsaved work, you should display a broken close button in all of them. The application should not bring up a Close panel, however, until the user closes the last window for the file.

---

The Mail application breaks the close button on a Send window as soon as a user types in the message area. If the user tries to close the window (either directly or by quitting the application), Mail puts up an attention panel that forces the user to either confirm the close or cancel it.

If an application does no work that can be saved, but merely shows data that might change, you can use the close button to indicate the status of the data. Break the close button to indicate that data in the window is not up to date. The application should also provide a way for the user to force the window to update. For an example of close buttons used in this way, look at the File Viewer.

Just as there is a command in the Windows menu ("miniaturize") that corresponds to the miniaturize button, there is one that corresponds to the close button ("Close"). It has a keyboard alternative, Command-w (for "window"). See "The Windows Menu" in Chapter 6 for details.

Implementing Window and Application Status

Most aspects of window and application status are handled by the Application Kit. You must choose the initial key window and decide which windows are allowed to become the key window. (For information on when to make a panel the key window, see Chapter 5, "Panels.") You need to make sure the application activates itself in the appropriate way, as discussed in the following paragraphs.

Choosing the Key Window

In general, every standard window in your application should be permitted to act as the key window, even if it does not respond to keyboard actions. Giving key window status to a window will focus attention on it and prevent the user from typing in any other window. When the key window does not accept typing, it should beep as it receives keystrokes, informing the user that typing is not appropriate.

When an application is activated on startup, it should designate one of its windows to be the initial key (and main) window. If the application opens a document file for the user, the window that displays the document should be the key window.

Activating an Application

Applications do not usually activate or deactivate themselves explicitly. When an application exchanges messages with the Workspace Manager, uses services, or provides services, activation and deactivation are handled by the system. For example, when the user chooses the Mail Selection service from Edit's Services menu, the Edit application is deactivated. Mail is then activated, on the condition that no other application is currently active. Since Edit has been deactivated, this condition will be met unless the user activates another application in the meantime.

The only time an application needs to explicitly activate or deactivate itself is when it communicates with another application without using the services system or the Workspace Manager. This might happen when two applications work together closely by sending messages directly to each other. If the intent of a message is to activate the receiving application, then the sender of the message should deactivate itself just before sending the message, and the receiver should conditionally activate itself when it receives the message. If the intent of a message is not to activate the other application, then neither application should activate or deactivate itself. In general, a message should conditionally activate the receiving application whenever the user might work in it--even if it is only to operate a scroller.

---

Note - Applications should avoid activating themselves unconditionally. Unconditional activation violates the principle of user control, since it ignores the user's desire to turn to something else.

---

---

Programmer's Note - As described in this subsection, most applications do not need to explicitly activate or deactivate themselves. However, when necessary, an application can conditionally activate itself with the following code:

[NSApp activateIgnoringOtherApps:NO];

An application can deactivate itself as follows:

[NSApp deactivate];

---

Avoiding Activation When Dragging

When a user drags an object, such as a color or a file, between two applications, both the area that originally contained the object (the source) and the area to which the object is dragged (the destination) need to be visible. Sometimes the user needs to move the windows of one or both applications to make this possible. Once the user starts to drag the object, a change in window order may cover up the destination. This could happen when the source application is not active. When the user begins to drag, the source application is activated, bringing its windows forward and perhaps covering the destination.

To prevent this, there is an exception to the standard activation behavior in this situation. When a user drags an object from one application to another, the drag should not activate the source's application. It should activate, however, when the user clicks anywhere in the source's window or begins a drag anywhere in the window except the source area.

---

Programmer's Note - Avoiding activation when dragging objects is fairly simple to implement. First, each NSView that contains draggable objects should override acceptsFirstMouse: so that it returns YES. This enables the NSView to receive events whether or not its window is the key window. Next, the NSView should override the shouldDelayWindowOrderingForEvent: method so that it returns YES when the passed mouse-down event occurred over a draggable object. (The shouldDelayWindowOrderingForEvent: message is sent just before the mouseDown: message for the event.)

That is all you have to do if you use the dragging system. The dragging system automatically calls the preventWindowOrdering method (which prevents the window's application from being activated) if the object is dragged. Unless the preventWindowOrdering method is called, the window's application is activated, as usual.

---