Method of Sizing or Moving Windows

The invention relates to a method of sizing or moving windows.

A window-sizing or moving method is known in particular from the Microsoft "Windows" multi-window multitasking program. This type of program has the disadvantage, when a window is being sized or moved, of blocking the development of applications running in the other windows.

The goal of the present invention is to overcome this disadvantage.

This goal is achieved by the fact that the window-sizing and moving method in a "Windows" application consists of interposing between "Windows" and the various applications running in "Windows," filters intercepting particular messages, processing these messages by a specific application, and sending to "Windows" a neutral message which triggers no action on the part of "Windows" and does not block the running of the other applications.

According to another feature, the processing conducted by the specific application consists of processing each of the particular events that can occur, corresponding potentially to a window move event or a window sizing event, and during this processing, of calling on specific functions allowing initialization of a number of parameters, W.sub.-- Top, W.sub.-- Right, W.sub.-- Bottom, W.sub.-- Left, W.sub.-- Caption, Frm.sub.-- CurPos, h.sub.-- WndCurr, which are stored until a later event occurs, triggering the end of processing.

According to another feature, the parameters stored are constituted by:

"h.sub.-- WndCurr"='h.sub.-- WndCurrent" which is a variable showing that an action has been started in any window;

"b.sub.-- LoadedIcon", to memorize that an icon has been loaded;

"h.sub.-- WndMenu", which is the variable showing, in the case of an icon, whether one is in a menu run or an icon move phase;

"h.sub.-- OldCursor", which is the variable allowing an identifier of the "Windows" active cursor to be memorized before the application is launched and the specific cursor of the application is replaced;

"w.sub.-- CXScreen", "w.sub.-- CYScreen", "w CXframe", "w.sub.-- CYMinHeight", "w.sub.-- CXMinWidth", which are the coordinate variables of the window during sizing, frame, and minimum width, respectively;

"Frm.sub.-- CurPos", which is the current frame position variable;

"Mse.sub.-- CurPos", which is the current mouse position variable;

"w.sub.-- Left", "w.sub.-- Top", "w.sub.-- Right", "w.sub.-- Bottom", "w.sub.-- Caption", which are the direction variables used to calculate the coordinates of the new window and the direction tests;

"Wnd.sub.-- StartPos", which is the variable defining the initial position of the window;

"Mse.sub.-- StartPos", which is the variable defining the initial position of the cursor;

"b.sub.-- Cursor" and "b.sub.-- LoadedIcon", which are the Boolean variables assumed to be false at the start.

According to another feature, there are two filters. A first "WM.sub.-- GETMESSAGE" filter allows messages posted by hardware interrupts such as:

WM.sub.-- NCLBUTTONDOWN

WM.sub.-- MOUSEMOVE

WM.sub.-- KEYDOWN

WM.sub.-- SYSKEYDOWN

to be received, and a second "WH.sub.-- CALLWNDPROC" filter allowing messages sent to the method [sic] such as:

WM.sub.-- SYSCOMMAND

WM.sub.-- ACTIVATEAPP

WM.sub.-- NCACTIVATE

WM.sub.-- ACTIVATE.

to be filtered and received.

According to another feature, intercepting a message triggers the processing of a program specific to each message and brings in the stored parameters and the principal processing functions such as:

ABMSInit to initialize processing,

ABMSMove to move the window,

ABMSEnd to end processing,

which themselves call utility functions.

According to another feature, the ABMSInit function is implemented only to process the messages "WM.sub.-- NCLBUTTONDOWN" and "SC.sub.-- SIZE" which is a message depending on "WM.sub.-- SYSCOMMAND."

According to another feature, the ABMSEnd function is implemented only to process the "WM.sub.-- LBUTTONUP" and "VK.sub.-- ESCAPE", "VK.sub.-- RETURN" messages which depend on "WM.sub.-- SYSKEYDOWN."

According to another feature, the ABMSMove function is implemented only to process "WM.sub.-- MOUSEMOVE, MK.sub.-- LEFT, VK.sub.-- UP, VK.sub.-- RIGHT, and VK.sub.-- DOWN" messages which are messages depending on "WM.sub.-- SYSKEYDOWN."

According to another feature, the ABMSInit function consists of appropriating mouse messages by the "SETCAPTURE" instruction, then looking to see whether the window is a child window of a parent window, namely written in the parent window to limit the movements of the child window, then initializing the initial coordinates of the window and the position of the cursor to become current coordinates and initializing the characteristic parameters of the window (w.sub.-- CXframe, w.sub.-- CXMinWidth, w.sub.-- CYMinHeight).

According to another feature, the method comprises the following stages:

transition of the filters to active mode;

memorizing the identifier of the "h.sub.-- Wnd" window to which the message is sent;

memorizing the type of action resulting from the click zone, which memorization is accomplished by the HitTest function and the ABMSInit function;

appropriating later mouse messages for the window in question;

first drawing of ghost frame around the window by the InvertBlock procedure;

neutralizing the message by replacing and substituting a "WM.sub.-- ENTERIDLE" message which is not processed and triggers no action on the part of "Windows".

According to another feature, the method includes the following stages:

calculating the final coordinates of the window by the ABMSComputNewPos procedure, erasing the ghost by InvertBlock;

drawing the window in the final position by the ABMSMove function;

resetting the memorization parameters to zero by the ABMSEnd function.

According to a last feature, the method also comprises the following stages:

abandoning ownership of the mouse messages by the "Release Capture" instruction;

passage of the filter into passive mode.

Other characteristics and advantages of the present invention will emerge more clearly from reading the description below, which refers to the attached drawings wherein:

FIG. 1 represents the general path diagram of the invention;

FIG. 2 represents the operating principle of the filters of the invention;

FIG. 3 represents a table of possible scenarios;

FIG. 4 is a flowchart of the interpretation program once the filtering function has been loaded;

FIG. 5 represents the prior art of the invention;

Appendices 1 to 8 show in detail the various stages represented in the flowchart of FIG. 4.

The invention relates to an improvement of a multitask, multi-window program operating on computer equipment comprising a central processing unit or processor, a display monitor, a keyboard resource, and a mouse.

In the prior art of FIG. 5, showing the operation of a program that allows several applications to be run with one or more windows per application, a number of drawbacks may be noted. Thus, in a "Windows" environment or OS2, the core (1) of the "Windows" program sends messages (30, 31) in the direction of the various applications or tasks (T1, T2, T3), namely (20, 21, 23), respectively. Core (1) of "Windows" allows messages (30, 31) to be sent to the activated tasks, for example in the case of FIG. 5, tasks (T1) and (T3), and these messages addressed to the respective task to be stacked in a respective queue (Q1, Q3). Core (1) of "Windows" attributes the processor to the application which will then manage the queued messages and process them, and when the queue is empty the task sends the processor to core (1) of "Windows" to allow attribution of the processor to another activated application. Each application (T1, T3) comprises an associated window (F1, F3). Each window constitutes a visible or an invisible object. With each window is associated a method which constitutes the use or reaction mode of the window to the various messages concerning the application window. This method is a program which processes each of the messages and performs actions as a consequence. This program can choose to process some of these messages or allow some others to be processed by "Windows." In the latter case, the application program calls for a message (33) to be sent to a function (13) of "Windows" core (1), which function is called "default Windows Proc." Core (1) of " Windows" is able to recognize these particular messages and, for example in the case of sizing a window or moving it, carries out standard processing. Thus, an operator who wishes to size a window will act on the system 'mouse" which, by interrupting the hardware, generates a number of messages. These messages will be sent and stacked in the queue (Q1), for example, of the application concerned. When it processes the queue, the program passes these messages to the method [sic] of the window, which tries to find out where the mouse is located, namely whether it is on an edge, in the middle, or on a menu zone of the window. Depending on this location, the method generates a number of different messages.

If the mouse is on an edge of the window, the resulting interrupt generates the message "WM.sub.-- LBUTTONDOWN." When the method recovers this message, it sends it to function (13) "Def Window Proc" and hands off to "Windows." "Windows" detecting this particular message, finds out from which zone of the window it was obtained and, depending on the case, generates a number of messages such as "WM.sub.-- SIZE" (corresponding to sizing the window) or "WM.sub.-- MOVE" (corresponding to moving the window) and waits for subsequent messages from the mouse so that it can process them immediately.

The messages sent (30, 31) can be either system messages sent by "Windows" core (1) directly to an application, or messages from the hardware, often after an interrupt, for example mouse messages or keyboard messages. When the method has sent a message to the "Def Wnd Proc" function and as long as the other information concerning window sizing or moving allowing function (13) to end processing the message, has not arrived at this function, the processor continues to execute this function, does not leave it, and waits for other messages. This has the disadvantage of blocking the process of processing other tasks. This disadvantage is particularly troublesome in real time applications, for example in real time monitoring or alarm control. In this type of application, it may occur that a window sizing or move maneuver using the keyboard is started and the interrupted operator blocks all the other applications for the entire time he is unable to complete his window sizing or moving action, using the keyboard or mouse.

Hence the goal of the invention is to eliminate this disadvantage and offers the architecture of FIG. 1 in which a filter (4) is placed between the various applications (20, 21, 22) and core (1) of "Windows," which filter is hooked to the "Windows" core which, when certain messages go through, ensures processing of these messages by an ABMS application (5). Thus, messages (301, 311, 321, 331) sent by the "Windows" core to applications A, B, C (20, 21, 22) go into filter (4) and, depending on activation or nonactivation, are transmitted or processed by ABMS. In the case of filter activation, certain types of messages are transmitted in the form of messages, (304) to application A, (324) to application B, and (314) to application C. In the case where one of the messages (301, 321, 311) corresponds to a specific event (50, 51, 52, 53) as shown in FIGS. 2 and 4, this message is intercepted and processed by application ABMS (5) as will be seen below.

Hence the invention is based on the use of message filters furnished by "Windows," these filters allowing any application to be informed of the passage of all the messages corresponding to a particular type of event and permitting them to be modified or replaced before they arrive at their true destination.

Thus, the ABMS application (5) uses two of these specific filters. Two filters are necessary to cover all the possible messages in the cases concerning us, because "Windows" classifies all the messages into message families and the messages that concern us belong to two of these families. A "WH.sub.-- GETMESSAGE" filter (400, Appendix 1) allows receipt of messages posted by the hardware interrupts, namely the mouse or keyboard, which messages would normally have been placed in the application queue. Another "WH.sub.-- CALLWNDPROC" (401, Appendix 1) allows all the messages which would be sent directly to the application method [sic] to be filtered and received. These filters are installed when the ABMS application is initialized, this installation being indicated by numeral (40) in FIG. 2 and Appendix 1, and being carried out by the "SETWINDOWSHOOK" function. Closure of the ABMS application withdraws the filters, this withdrawal being shown by numeral (41) in FIG. 2 and Appendix 1, and is effected by the "UNHOOKWINDOWSHOOK" function. These installed filters can be passive, i.e. not affecting the messages, or active, namely causing a particular kind of processing arising from a certain specific event. In the case where the filter is passive, messages (301, 321, 311) arriving in the filter will be transmitted to the applications in the form of distributed messages (304, 324, 314), and in the case where the filter is active, it will send the message to the ABMS application for processing.

The options taken into account by the ABMS application can be divided into a number of scenarios which are classified in a threedimensional table (see FIG. 3) representing the actions, the means employed, and the status of the manipulated window. Realization of the ABMS application required a number of difficulties to be overcome, some of them general and noted below, and others specific to a scenario and indicated in the corresponding box in FIG. 3.

The general difficulties relate to terminating the action when canceled by the ESC key. At this time, restoration of the initial status assumes memorization of a number of pieces of information constituted by variables remaining in the data zone of the ABMS application. Another difficulty is interpenetration of keyboard/mouse scenarios. In fact, the frontier between the keyboard and mouse scenarios is not sealed so that a restart action with one of these means can be continued with the other at any time. ABMS takes this flexibility into account. Each message processed causes the general context of the application to evolve by modifying the contents of the variables or operating on parameters defined in the ABMS data zone, and leaves these variables in a clearly defined status that can be taken over by any other message. These variables are represented by:

"h.sub.-- WndCurr," which is a variable showing that an action has been started in a window;

"h.sub.-- WndMenu," which is the variable showing, in the case of an icon, whether one is in a menu run phase or an icon move phase;

"h.sub.-- OldCursor," which is the variable allowing a Windows active cursor identifier to be memorized before the application is launched and the specific cursor of the application to be replaced;

"w.sub.-- CXScreen," "w.sub.-- CYScreen, w.sub.-- CXframe, "w.sub.-- CYMinHeight, w.sub.-- CXMinWidth," "which are the variables of the window coordinates during sizing, frame, and minimum width;

"Frm.sub.-- CurPos," which is the current position variable of the frame;

"Mse.sub.-- CurPos," which is the current position variable of the mouse;

"w.sub.-- Left, w.sub.-- Top," "w.sub.-- Right," "w.sub.-- Bottom" "w.sub.-- Caption," , which are the direction variables used to calculate the coordinates of the new window and the direction tests;

"Wnd.sub.-- StartPos," which is the definition variable of the initial window position;

"Mse.sub.-- StartPos," which is the definition variable of the initial cursor position;

"b.sub.-- Cursor" and "b.sub.-- LoadedIcon," which are Boolean variables assumed to be false at the start.

In the case of sizing a window which is not an icon, done only by the mouse, the operator must carry out the following operations:

He positions the mouse cursor on one of the edges of the window, presses the left button, and holds it down. He then moves the mouse, which has the effect of moving one of the edges of the frame representing the window ghost, on the screen. When the user believes he has reached the desired size, he releases the left button and the window is redrawn in the frame which has just been redefined. At the beginning of the operation, the filter installed by ABMS is initially in the passive state. All mouse move messages sent by "Windows" core (1) are distributed. When the operator presses the left mouse button, the cursor being at the edge of the window, "Windows" generates a "WM.sub.-- NCLBUTTONDOWN" message whose parameters contain the window identifier and a value defining the zone at which the event occurred. The ABMS actions are then the following:

transition to active mode, memorization of identifier of HWND window for which the message and the initial coordinates are intended;

memorization of the type of action resulting from the click zone (left, right, top, bottom, diagonal sizing); this memorization is done by the ABMSHit test portion of the program numbered (501) in Appendices 1 and 7 and by the ABMSInit program numbered (502, 503) in Appendix 3;

appropriation of subsequent mouse messages (by the SETCAPTURE instruction) for the window in question;

first drawing of the ghost frame around the window by the ABMSInvertBlock procedure shown in Appendix 4 by number (521) which, upon each movement, cancels the previous ghost frame and redraws the next one at the new location;

neutralization of the message by replacing and substituting a "WM.sub.-- ENTERIDLE" message which is not processed and causes no action by "Windows."

When the ABMS program is launched, a first function, shown by numeral (40) in Appendix 1, installs or deinstalls the filter function. The filter function is installed by the "SETWINDOWSHOOK" function and deinstallation is done by the "UNHOOKWINDOWSHOOK" function as shown by numerals (40, 41) in FIG. 2. Once this filter function is activated, all messages such as "WM.sub.-- SYSCOMMAND, WM.sub.-- LBUTTONUP, WM.sub.-- SYSKEYDOWN, WM.sub.-- NCLBUTTONDOWN, WM.sub.-- MOUSEMOVE" are diverted, processed by the ABMSHook program, and neutralized by sending the "WM.sub.-- ENTERIDLE" message of the application to "Windows." All these messages are initially sent by "Windows" after a keyboard or mouse interrupt.

Thus, as shown in FIG. 4, when the WM.sub.-- NCLBUTTONDOWN" message, number (50), is sent by "Windows," this message is intercepted by the ABMSHook program which, in the first phase (504) memorizes the identifier of the window for which the message is intended, in variable "h.sub.-- WndCurr", runs a test to find out whether the window is an icon, this test being shown in program (50) of Appendix 1 by line (500), memorizes the type of action resulting from the clicking zone by the portion of ABMSHit test program (501), Appendix 1, shown in detail in Appendix 7 by numeral (501), and runs subprogram ABMSInit (502, 503) in Appendix 1, shown in detail in Appendix 4 by numerals (502, 503). This program appropriates the later mouse messages by the "SETCAPTURE" message for the window in question and determines the initial coordinates of the window and of the cursor position. "WM.sub.-- NCLBUTTONDOWN" processing sequence (50) sends back the "WM.sub.-- ENTERIDLE" message at the end of processing.

The next message, sent by Windows, can be a mouse movement, indicated by the "WM.sub.-- MOUSEMOVE" message and processed by the instruction sequence (51) in Appendix 1 at the end of which the program hands off to Windows by sending the "WM ENTERIDLE" message. The other instruction possibility is a mouse button release instruction, this instruction being indicated by the Windows message "WM.sub.-- LBUTTONUP" whose processing sequence (52) is shown in Appendix 1. This sequence launches subprogram ABMSEnd which, at the end, hands off to core (1) of Windows to send the "WM.sub.-- ENTERIDLE."

In the case of a "WM MOUSEMOVE" message sent by Windows, the program looks to see if the object is iconic by numeral (510) in Appendix 1; if it is not iconic, instruction (515) looks to see whether the direction variables have been in itialized and in this case launches the ABMSMove function (511), Appendix 5, and if not, the ABMSDirection function (512), Appendix 6, is launched to initialize the direction variables with the result of the ABMSTestDirect function (513), Appendix 8, as parameters. If the object is iconic, the sequence launches, by instruction number (5111), loading of the icon at the position indicated by the cursor and the ABMSLoadIcon function (5100). The sequence then hands off to Windows, sending the "WM.sub.-- ENTERIDLE" message.

When ABMS intercepts a "WM.sub.-- SYSKEYDOWN" message represented by numeral (53) in FIG. 4, processing of this message starts subprogram (53) which begins by processing the case of activation of a carriage return key when a "VK.sub.-- RETURN" message or an escape message "VK.sub.-- ESCAPE" is received and then processes the case of the left move key "VK.sub.-- LEFT," up move key

"VK.sub.-- UP," right move key "VK.sub.-- RIGHT," and down move key "VK.sub.-- DOWN." Depending on the type of key depressed, it carries out the processing corresponding to one of the subprograms: (530) for leftward movement, (531) for upward movement, (532) for rightward movement, and (533) for downward movement.

As explained above, as soon as a message is received by the filter it is processed and the ABMS program, after the corresponding processing, hands off to core (1) of Windows which can then hand off to another application while waiting for the filter to intercept a new message whose processing requires intervention of the ABMS program. The filter remains active until the operator releases the left mouse button or hits "Enter" or "Esc." This action generates a "WM.sub.-- LBUTTONUP, WM.sub.-- SYSKEYDOWN, VK.sub.-- ENTER, VK.sub.-- ESCAPE" message which brings about the change in status of the ABMS filter from the active status to the passive status. The actions performed during this change are the following:

calculation of final window coordinates by the ABMSComputNewPos procedure, represented by subprogram (5210) in Appendix 5;

erasure of ghost by InvertBlock;

drawing window in final position;

resetting of memorized parameters to zero;

abandonment of ownership of mouse messages by "Release Capture" instruction;

transition of filter to passive mode.

As has just been explained, the ABMS application, because of the filter installed, receives the various messages "WM.sub.-- SYSCOMMAND, WM.sub.-- NCLBUTTONDOWN, WM.sub.-- MOUSEMOVE, WM.sub.-- LBUTTONUP, WM.sub.-- SYSKEYDOWN, WM.sub.-- KEYDOWN, WM.sub.-- ACTIVATEAPP, WM.sub.-- NCACTIVATE, WM ACTIVATE." This application replaces these messages, for the benefit of Windows, with a neutral message such as "WM ENTERIDLE" and then proceeds to process these messages, calling various principal processing functions called when it is detected that a processing is initialized. These principal processing functions are:

the ABMSInit function to initialize processing when a first "SC.sub.-- MOVE" or an "SC.sub.-- SIZE" is received in a "WM SYSCOMMAND";

This ABMSInit function consists of appropriating the mouse messages by the "SETCAPTURE" instruction, then looking to see whether the window is a child window of a parent window, namely written in the parent window to limit the movements of the child window, then initializing the initial window coordinates and the cursor position to become the current coordinates and initializing the characteristic parameters of the window (w.sub.-- CXFrame, w.sub.-- CXMinWidth, w.sub.-- CYMinHeight).

then the ABMSEnd and the ABMSMove functions.

In addition to these three principal functions, there are utility functions called up at different points of the principal functions, which serve to carry out utility processing. These functions are:

The ABMSComputNewPos function which, when it is given the mouse coordinates, serves to calculate and update the window coordinates, taking global and remanent variables into account. This ABMSComputNewPos function (5210), Appendix 5, allows the new positions to be calculated from the W left, W.sub.-- Caption, W.sub.-- Top, W.sub.-- Right, and W.sub.-- Bottom parameters and the coordinates of the mouse and window frame to be calculated from the minimum height and width coordinates of the windows. It also tests the limits of these calculations, to ensure that a child window does not exit from a parent window.

The ABMSDirection function (512), Appendix 6, serves to determine the shape of the cursor and to initialize the direction variables as a function of the messages received. This ABMSDirection function (512), Appendix 6, for example in the case where the parameter sent back by ABMSTestDirection is D.sub.-- Top, positions the W.sub.-- Top parameter at 1 and hooks the cursor position to the upper edge of the window by instruction number (5120), then the sequence tests the W.sub.-- Left parameter to find out whether W Left is initialized and, if it is, sends the message "D.sub.-- TTOBDBLEARROW" to ask whether the cursor display is inclined at 40.degree. upward and rightward. If W.sub.-- Left is not initialized, the sequence looks to see whether W.sub.-- Right is initialized and, if so, sends the message "D.sub.-- BTOTDBLEARROW" to request the cursor to be displayed inclined upward and leftward, and if the test on W.sub.-- Right is negative, a vertical cursor is displayed by execution of the "D.sub.-- VERTDBLEARROW" message.

The function ABMSHitTest (501), Appendix 7, serves to determine upon initialization which zone has been clicked in to initialize the direction variables in the case of mouse movements. This function is called up by ABMSInit in the case where "WM.sub.-- NCLBUTTONDOWN" is received and allows the W.sub.-- Top, W.sub.-- Right, W.sub.-- Bottom, W.sub.-- Left, and W.sub.-- Caption variables to be initialized.

Thus, as can be seen in Appendix 7 when an HT.sub.-- TopRight message is received, indicating that the top right corner has been clicked by the mouse, the ABMSHitTest function sets the W.sub.-- Top and W.sub.-- Right variables to zero which, when a new message is received, shows whether initialization has occurred in the upper right corner of the window and hence window movement or window sizing must be processed.

The ABMSInvertBlock function, represented by numeral (5030), Appendix 7, draws the rectangle by drawing four adjacent rectangles commanded by the PatBlt function as a function of the hDC parameters and the dimensions of the window represented for example by P.sub.-- RecFrm.left. This PatBlt function by the DSTINVERT command, at the same time inverts the window ghost.

The ABMSLoadCursor function (5031), Appendix 7, which loads the cursor as a function of the parameters sent which depend on the position of the window's edge; thus, if the W.sub.-- Left and W.sub.-- Top parameters are initialized at 1, one is dealing with the upper left edge of the window and the cursor initialized will look like an arrow pointing at the lower right edge of the window, namely at 45.degree..

The ABMSLoadIcon function (5100), Appendix 8, which, when a static icon has been moved, allows the cursor to be replaced by the image of the static icon generated by Windows, and if a dynamic icon has been moved, allows this dynamic icon image to be replaced by an image constituted by the cursor.

The ABMSTestDirect function, shown at numeral (513) of Appendix 8, determines the parameter to be sent back, for example D.sub.-- Left (5130), by testing the information received by the application and sent by Windows, constituted by the X coordinate of the position of the mouse represented by P.sub.-- MSEPOS.X and compares this coordinate to the value of the left position of the window, and if the value of the X coordinate of the mouse is less than the abscissa of the window's left edge, this function returns the D.sub.-- Left message to the application. This function is used in conjunction with the ABMSDirection function,

The ABMSMove function (511), Appendix 5, allows the window to be moved by inverting the ghost of the window by the ABMSInvertBlock function, represented by reference (5030) in Appendices 5 and 7, then calculates the new position of the window by the ABMSComputNewPos function (5210), and finally inverts the window ghost for the new position calculated, represented by reference (5112).

The ABMSEnd function (521), Appendix 4, ends the process by using instruction (5211) to find out whether the window is iconic. If it is not iconic, the ending is a normal ending (5212), namely launching the ABMSComputNewPos function (5210); if not, the cursor, by instruction (5213), resumes its initial starting position. By sequence (5214), this function also allows it to be determined whether the window being processed is a child window and in this case converts the coordinates before a movement. Likewise, this function, if necessary, uses sequence (5215) to restore the cursor and resets the parameters to zero by sequence (5216).

Application by the CalMsgHook filter allows messages which would have been sent directly to the application method, including the "WM.sub.-- SYSCOMMAND, WM.sub.-- ACTIVATEAPP, WM.sub.-- NCACTIVATE, WM.sub.-- ACTIVATE" messages, to be filtered and received. Processing of the "WM.sub.-- SYSCOMMAND" message shown at (54) can be broken down into processing either of a "SC.sub.-- MOVE" or of a "SC SIZE" message. The "SC.sub.-- SIZE" message positions the W.sub.-- Caption parameters at 1 and the window sizing message "SC.sub.-- SIZE" triggers the processing represented by number (540). When the application receives a window sizing message, it asks (5401) for the cursor position, requiring it to be that of the mouse. Then, at (5402) this procedure launches the ABMSInit function and the cursor position (5403) is made to agree with the action performed and at the end of processing the application sends back to Windows the message "WM.sub.-- ENTERIDLE," numbered 541, which thus replaces the "WM.sub.-- SYSCOMMAND" message.

Likewise, the GetMsgHook filter filters the "WM.sub.-- NCLBUTTONDOWN, WM.sub.-- MOUSEMOVE, WM.sub.-- LBUTTONUP, WM.sub.-- KEYDOWN, WM.sub.-- SYSKEYDOWN" messages. When such a "WM.sub.-- NCLBUTTONDOWN" message arrives at the ABMS application, using instruction number 504, one looks to see whether it is a menu run or not. If it is not a menu run, one looks at number 500 to see whether one is working for an icon. If one is not working for an icon, one looks to see whether the parameters have been initialized by the ABMSHitTest function (501). If the parameters have not been initialized, one launches the ABMSInit function (502, 503) by storing in the point the X and Y coordinates furnished by the message parameter, and then the "WM.sub.-- ENTERIDLE" message (505) is sent to Windows to hand off to it. In the case of a "WM.sub.-- MOUSEMOVE" message sent by Windows, the program looks at (510), Appendix 1, to see whether the object is iconic; if it is not iconic, instruction (515) looks to see whether the direction variables have been initialized and in this case launches the ABMSMove (511) function, Appendix 5; if not, the ABMSDirection function (512), Appendix 6, is launched to initialize the direction variables with the result of the ABMSTestDirect function (513), Appendix 8, as parameters. If the object is iconic, the sequence uses instruction (5111) to launch loading of the icon at the position indicated by the cursor and function ABMSLoadIcon (5100). Next, the sequence hands off to Windows by sending the message "WM.sub.-- ENTERIDLE."

If the message "WM.sub.-- LBUTTONUP" is received from the application, one looks at (510) to see whether the operator has run the menu; if not, the application looks to see whether the window coordinate corresponds to the mouse coordinate and launches the ABMSEnd function (521) and then sends the "WM.sub.-- ENTERIDLE" message to Windows.

In the case of messages sent after a key is depressed, the application begins at numeral 534 to handle the case of abort keys constituted by the escape (VK.sub.-- ESCAPE) and carriage return (VK.sub.-- RETURN) keys. If this is not the case and the application has received the VK.sub.-- Left message, the application first looks at the sequence numbered 530 if in the icon mode and loads the icon by function ABMSLoadIcon (5100), then looks using instruction (5301) to see whether parameters W.sub.-- Caption, W.sub.-- Left, and W.sub.-- Right have been initialized and, if they have, moves the icon or gives it the actual magnitude by sequence (5302). If the icon mode is not operating at this point in time, the ABMSMove function is launched and the position of the mouse is given to the position of the cursor. Otherwise, ABMS launches the ABMSDirection function and then sends the message "WM.sub.-- ENTERIDLE" back to Windows.

The operation of the other parts of the program handling the various events that can occur and calling on the main processing functions or on the utility functions may be deduced from the above explanations and the listing in the appendices.

Any modification within the reach of the individual skilled in the art will also be part of the spirit of the invention. ##SPC1##