FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

WINDOWS

Understand the difference between _WndActivate and _WndRefresh


Clicking on a window causes (with exceptions noted below) only a _wndClick event. Your program would (normally) respond to such an event by bringing the window to the front, which you do via the WINDOW statement. Bringing the window to the front always causes a _wndActivate event. If bringing the window to the front _also_ happens to cause some previously-covered part of the window to become visible, then a _wndRefresh event is generated.

So a _wndActivate event is often, but not necessarily, followed shortly thereafter by a _wndRefresh event. You could bring the window from the "back" to the "front" even if nothing was in front of it. In this case, the window's highlighting changes to indicate that it's now active, but no refresh event occurs (a change in the highlighting doesn't count as a "refresh").

By the same token, a _wndRefresh event can occur without a _wndActivate event. Suppose window "A" is active (frontmost) and is partially covering window "B". If you drag "A" off to the side, you have not changed the active window ("A" is still active) so there's no _wndActivate event. But you've now uncovered some more of "B", so "B" needs to be refreshed. This causes a _wndRefresh event to be generated for window "B".

Now, about those "exceptions" I mentioned above: Clicking on a (non-active) window's _title_ bar (or, in OS 8, clicking anywhere on the window's _border_) will _not_ generate a _wndClick event. In this case, FB just activates the window automatically (at the next HANDLEEVENTS), without waiting for you to execute the WINDOW statement. The only way you can tell that FB has switched you to a new window, in that case, is to watch for the resulting _wndActivate event.

To summarize:

* Clicking in a non-active window (except in its title bar or (in OS 8) its border) generates a _wndClick event.

&Mac183; Activating a non-active window (generally this means "bringing it to the front") generates a _wndActivate event. There are two ways to activate a window:
&Mac183; (1) the program can activate it explicitly, by executing the WINDOW statement;
&Mac183; or
&Mac183; (2) FB can activate it independently, in response to a click in the window's title bar (or border). (A _wndActivate event is also generated for any window which has just become _inactive_. In this case the "id" for the event is the _negative_ of the inactivated window's ID

* Revealing any part of (any) window that was previously covered or hidden generates a _wndRefresh event. (Resizing a window--even if you only make it smaller--also generates a _wndRefresh event.)

Rick


Note

The two dialog events are very different. A refresh event is generated by the system when it considers that a window needs refreshing. It could be either the active or a non-active window.

An activate event comes when a user clicks in a non-active window. Under the Mac GUI, this would normally mean that the user wants to make that window the active window, in which case you would need to react to the activate event with a WINDOW command.

If you, as the programmer, don't want to make the window active, you don't have to - for example you may want to treat the mouse click as any other (for example in a palette). At the activate command, you could then route the mouse click to the mouse event handler instead. (But note you'll need to switch from global to local coordinates when you do so)

Note that the mouse click does _not_ generate an update event.

Phil Yates