WO1992002921A1 - Procede de retaillage ou de deplacement de fenetres - Google Patents

Procede de retaillage ou de deplacement de fenetres Download PDF

Info

Publication number
WO1992002921A1
WO1992002921A1 PCT/FR1991/000612 FR9100612W WO9202921A1 WO 1992002921 A1 WO1992002921 A1 WO 1992002921A1 FR 9100612 W FR9100612 W FR 9100612W WO 9202921 A1 WO9202921 A1 WO 9202921A1
Authority
WO
WIPO (PCT)
Prior art keywords
window
messages
windows
message
function
Prior art date
Application number
PCT/FR1991/000612
Other languages
English (en)
Inventor
Alain Bouchet
Alain Marie-Sainte
Original Assignee
Bull S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull S.A. filed Critical Bull S.A.
Publication of WO1992002921A1 publication Critical patent/WO1992002921A1/fr

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/14—Display of multiple viewports

Definitions

  • PROCESS FOR FITTING OR MOVING WINDOWS PROCESS FOR FITTING OR MOVING WINDOWS.
  • the invention relates to a method of resizing or moving windows.
  • a method of resizing or moving a window is known, in particular by Microsoft "Windows" multitasking software.
  • This type of software has the disadvantage in the case of resizing or moving a window of blocking the evolution of applications that run in other windows.
  • the object of the present invention is to overcome this drawback.
  • the processing carried out by the specific application consists in processing each of the particular events which may occur and which potentially correspond to an event of displacement of the window or resizing of a window, and during this processing to call specific functions allowing on the one hand to initialize a certain number of parameters W_Top, W_Right, W_Bottom, W_Left, W_Caption, Frm_CurPos, h_WndCurr kept until the occurrence of a subsequent event which will cause the end of the processing.
  • the parameters retained consist of:
  • h_WndCurr "h_WndCurrent, which is a variable allowing to know that an action has been initiated on any window;
  • h_WndMenu which is the variable allowing to know, in the case of an icon, whether one is in a menu unwinding phase or an icon displacement phase;
  • the filters are in number of 2.
  • a first "WM_GETMESSAGE" allowing to receive messages posted by hardware interrupts, such as:
  • the interception of a message triggers the processing of a program specific to each message and involves the stored parameters and main processing functions, such as:
  • the ABMSInit function is implemented only for the processing of the "WM_NCLBUTTONDOWN" and “SC_SIZE" messages which is a message dependent on "WM_SYSCOMMAND".
  • the ABMSEnd function is implemented only for the processing of the "WM_LBUTTONUP” and “VK_ESCAPE", VK-RETURN "messages which depend on” WM_SYSKEYDOWN ".
  • the ABMSMove function is implemented only for the processing of the messages "WM_MOUSEMOVE, MK_LEFT, VK_UP, VK_RIGHT and VK_DOWN" which are messages dependent on “WM_SYSKEYDOWN”.
  • the ABMSInit function consists in appropriating the mouse messages by the instruction "SETCAPTURE", then in checking if the window is a child window of a mother window, that is to say registered in the mother window to limit the movements of the daughter window , then initialize the initial coordinates of the window and the cursor position to become the current coordinates and initialize the characteristic parameters of the window (w_CXframe, w_CXMinWidth, w_CYMinHeigth).
  • the method comprises the following steps:
  • the method comprises the following steps:
  • the method further comprises the following steps: abandonment of the ownership of mouse messages by the "Release Capture” instruction; - passage of the filter in passing mode.
  • Appendices 1 to 8 show the details of the different steps shown in the flowchart of Figure 4;
  • the invention relates to an improvement to multitasking and multi-window software operating on computer hardware comprising a central processing unit or processor, a display monitor, a keyboard resource and a mouse.
  • the kernel (1) of the "Windows” software sends messages (30, 31) to the various applications or tasks (T1, T2, T3), respectively (20, 21, 23).
  • the core (1) of "Windows” makes it possible to address messages (30, 31) to the activated tasks, for example in the case of FIG. 5, the tasks (T1) and (T3), and to stack these addressed messages to the respective task in a respective queue
  • Each application (T1, T3) has an associated window (F1, F3).
  • Each window constitutes a visible or invisible object.
  • Each window is associated with a method which constitutes the instructions for use or reaction of the window to the various messages which relate to the window of the application. This method is a program that processes each message and performs actions accordingly. This program can choose to process some of these messages or let others handle "Windows".
  • the application program provides for sending a message (32) to a function (13) in the kernel (1) of "Windows", a function which is called "default Windows Proc".
  • the "Windows" kernel (1) knows how to recognize these particular messages and performs, for example in the case of resizing a window or moving it, standard processing.
  • an operator who wants to resize a window will act on the "mouse" of the system which generates by hardware interruptions a certain number of messages.
  • These messages will be sent and stacked in the queue, for example (Q1), of the application concerned.
  • the program when processing the queue, passes these messages to the window method which seeks to know where the mouse is, that is to say if it is on an edge, in the middle, or on a window menu area. Depending on this location, the method generates a number of separate messages.
  • the resulting interruption generates the message "WM_LBUTTONDOWN".
  • the method retrieves this message, it sends it to the function (13) "Def Window Proc” and returns control to "Windows".
  • "Windows” detecting this particular message, inquires about which area of the window it was obtained, and depending on the case, generates a certain number of messages, such as "WM_SIZE” (corresponding to a resizing of the window ) or "WM_MOVE" (corresponding to a movement of the window) and waits for the following messages from the mouse so that they can be processed immediately.
  • the messages (30, 31) sent can be either system messages sent by the "Windows" kernel (1) directly to an application, or messages from the Hardware, often after an interruption, for example mouse messages or keyboard messages.
  • the method sent a message to the "Def Wnd Proc" function, and as long as the other information concerning the resizing or the displacement of the window allowing the function (13) to finish the processing of the message did not reach this function the processor continues to execute this function, does not leave it any more and it starts to wait for other messages.
  • This has the disadvantage of blocking the process for processing other tasks.
  • This drawback is particularly troublesome for real-time applications, for example, real-time monitoring or alarm control. In this type of application, it may happen that a resizing or window movement maneuver by keyboard is launched and that the disturbed operator blocks all the other applications during the entire time when he has not had the opportunity to finish cutting or moving a window, using the keyboard or the mouse.
  • the invention therefore aims to eliminate this drawback and proposes the architecture of FIG. 1 in which, between the different applications (20, 21, 22) and the core (1) of "Windows", is placed a filter (4) , attached to the "Windows" kernel, which during the passage of certain messages will ensure the processing of these messages by an ABMS application (5).
  • messages (301, 321, 331) sent by the "Windows" kernel to applications A, B, C (20, 21, 22) pass through the filter (4), and depending on the activation or non-activation activation are transmitted or processed by ABMS.
  • the filter is activated, certain types of messages are transmitted in the form of messages (304) to application A, (324) to application B and (314) to application C.
  • one of the messages (301, 321, 313) corresponds to a specific event (50, 51, 52, 53), as shown in Figures 2 and 4, this message is intercepted and processed by the ABMS application (5) , as we will see later.
  • the invention is therefore based on the use of message filters provided by Windows, these filters allowing any application to be informed of the passage of all messages corresponding to a particular type of event and to modify or replace them before that they do not reach their true recipient.
  • the ABMS (5) application therefore uses two of these specific filters. Two filters are necessary to cover all the possible messages in the cases which interest us, because Windows classifies all the messages by families of messages and the messages which interest us belong to two of these families.
  • a "WM_GETMESSAGE" filter (400, Appendix 1) allows you to receive messages posted by hardware interrupts, that is to say the mouse or the keyboard, messages which would normally have been deposited in the application queue.
  • WH_CALLWNDPROC (401, appendix 1) makes it possible to filter and receive all the messages which would be sent directly to the method of the application.
  • These filters are installed during the initialization of the ABMS application, this installation being represented by the reference (40) in FIG. 2 and in appendix 1, and being carried out by the "SETWINDOWSHOOK” function.
  • Closing the ABMS application removes the filters, this removal being represented by the reference (41) in FIG. 2 and in appendix 1 and carried out by the "UNHOOKWINDOWSHOOK” function.
  • These filters installed can be passing, that is to say not affecting messages or active, that is to say causing a specific processing occurring from a certain specific event.
  • the messages (301, 321, 311) arriving in the filter will be transmitted to the applications in the form of a distributed message (304, 324, 314), and in the case where the filter is active, will send the message to the ABMS application for processing.
  • the options taken into account by the ABMS application can be broken down into various scenarios which are classified in a three-dimensional table (see Figure 3) representing the actions, the means used and the states of the window used.
  • the realization of the ABMS application required the solution of a certain number of difficulties, some general and recalled below, others specific to a scenario and indicated in the corresponding box of Figure 3.
  • a first function represented in appendix 1 by the reference (40), installs or uninstalls the filter function.
  • the filter function is installed using the "SETWINDOWSHOOK” function, and. the uninstallation is done by the "UNHOOKWINDOWSHOOK” function, as represented in FIG. 2 by the references (40, 41).
  • all messages such as "WM_SYSCOMMAND, WM_LBUTTONUP, WM_SYSKEYDOWN, WM_NCLBUTTONDOWN, WM_MOUSEMOVE” are diverted, processed by the ABMSHook program and neutralized by sending the message "WM_ENTERIDLE" from the application to "Windows". All these messages are initially sent by "Windows” following a keyboard or mouse interruption.
  • This program appropriates the subsequent mouse messages with the message "SETCAPTURE" on behalf of the window in question and determines the initial coordinates of the window and the position of the cursor.
  • the processing sequence (50) of "WM_NCLBUTTONDOWN” returns the message “WM_ENTERIDLE” at the end of the processing.
  • the following message, sent by Windows, can be a movement of the mouse, indicated by the message "WM_MOUSE
  • This sequence launches the ABMSEnd subroutine which in the end gives control to the Windows kernel (1) for sending the message "WMJENTERIDLE".
  • the ABMS application thanks to the filter installed, receives the various messages "WM_SYSCOMMAND, WM_NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WM_SYSKEYDOWN, WM_KEYDOWN, WM_ACTIVATEAPP, WM_NCACTIVATE, WM_ This application replaces these messages, for Windows, with a neutral message such as "WM_ENTERIDLE” and then proceeds to process these messages by calling on various main processing functions called when a processing is detected. initialized. These main processing functions are:
  • This ABMSInit function consists in appropriating the mouse messages by the "SETCAPTURE" instruction, then in looking at whether the window is a child window of a mother window, that is to say registered in the mother window to limit the movements of the daughter window, then initialize the initial coordinates of the window and the cursor position to become the current coordinates and to initialize the characteristic parameters of the window (w_CXFrame, w_CXMinWidth, w_CYMinHeight).
  • ABMSComputNewPos the ABMSComputNewPos function which is used, when given the coordinates of the mouse, to calculate and update the coordinates of the window taking into account the global and remanent variables.
  • This function ABMSComputNewPos (5210), appendix 5 allows to calculate the new positions from the parameters W_left, W_Caption, W_Top, W_Right, W_Bottom and the coordinates of the mouse and the window frame, as well as from the minimum coordinates in height and width of the windows. It also tests the limits of these calculations to ensure that a daughter window does not come out of a parent window.
  • the ABMSDirection (512) function, appendix 6 is used to determine the shape of the cursor and to initialize the direction variables as a function of the messages received.
  • This function ABMSDirection (512), appendix 6, for example in the case where the parameter returned by ABMSTestDirection is D_Top, positions the parameter W_Top at 1 and hooks the position of the cursor at the upper edge of the window by the instruction referenced (5120) , then the sequence performs a test on the W_Left parameter to know if W_Left is initialized and in the affirmative case, sends the message "D_TTOBDBLEARROW" to request the display of the cursor tilted 45 ° up and to the right.
  • W_Left is not initialized, the sequence checks if W_Right is initialized and in this case sends the message "D_BTOTDBLEARROW" to request the display of the cursor tilted up and to the left, and in the case where the test on W_Right is negative, a vertical cursor is displayed by executing the message "D-VERTDBLEARROW".
  • ABMSHitTest (501), appendix 7, is used to determine at initialization in which zone one has clicked to initialize, in the case of mouse movements, the direction variables. This function is called by ABMSInit in the case where we receive a "WM_NCLBUTTONDOWN" and allows to initialize the variables W_Top, W_Right, W_Bottom, W_Left and W_Caption.
  • the ABMSHitTest function sets the variables W_To ⁇ and W_Right which will allow next, when receiving a new message to know that there has been an initialization in the upper right corner of the window, and that therefore, we must deal with moving the window or resizing it .
  • the ABMSInvertBlock function represented by the reference (5030)
  • appendix 7 draws the rectangle by drawing four adjacent rectangles controlled by the PatBlt function, according to the hDC parameters and the dimensions of the window represented for example by P_RecFrm.left .
  • This PatBlt function simultaneously performs the DSTINVERT command to invert the phantom of the window.
  • ABMSLoadCursor 5031
  • appendix 7 which loads the cursor according to the parameters sent which depend on the position on the edge of the window; thus, if the parameters W_Left and W_Top are initialized to 1, we have case at the top left edge of the window, and the initialized cursor will look like an arrow pointing towards the bottom right edge of the window, that is to say at 45o.
  • the ABMSLoadlcon (5100) function appendix 8, which allows when you move a static icon to replace the cursor with the image of the static icon generated by Windows, and in the case where you move a dynamic icon to replace this dynamic icon image by an image constituted by the cursor.
  • the ABMSTestDirect function represented at the reference (513) of appendix 8, makes it possible to determine the parameter to be returned, for example D_Left (5130), by carrying out a test on the information received by the application and sent by Windows , constituted by the X coordinate of the position of the mouse represented by P_MSEPOS.X and to compare this coordinate with the value of the left position of the window, and in the case where the value of the X coordinate of the mouse is lower than the abscissa of the left edge of the window, this function returns the message D_Left to the application.
  • This function is used in conjunction with the ABMSDirection function.
  • the ABMSMove (511) function, appendix 5 allows the window movement to be carried out by reversing the phantom of the window by the ABMSInvertBlock function, represented by the reference (5030) in appendices 5 and 7, then then calculating the new window position by the function ABMSComputNewPos (5210), and finally to invert the phantom of the window for the new calculated position, represented by the reference (5112).
  • the function ABMSEnd (521), appendix 4 terminates the process by looking through the instruction (5211) if the window is iconic. If it is not iconic, we end with a normal end (5212), that is to say by launching the function ABMSComputNewPos (5210), otherwise the cursor resumes with the instruction (5213) the initial position it had at the start.
  • This function also allows by the sequence (5214) to determine if the window in treatment is a child window and in this case to convert the coordinates before a movement. Likewise, this function, if necessary, restores the cursor by the sequence (5215) and resets the parameters to 0 by the sequence (5216).
  • CalMsgHook filter makes it possible to filter and receive messages that would have been sent directly to the application method, including the messages "WM_SYSCOMMAND, WM_ACTIVATEAPP, WM_NCACTIVATE, WM_ACTIVATE".
  • the processing of the message "WM_SYSCOMMAND”, represented in (54), can be broken down into processing, either of a message "SC_MOVE", or of a message ", SC_SIZE".
  • the message “SC_SIZE” sets the W_Caption parameters to 1, and the window resizing message "SC_SIZE” causes the processing represented by the reference (540).
  • the application When the application receives a resizing message from the window, it requests (5401) the position of the cursor, imposing that it be that of the mouse. Then, this procedure launches in (5402) the function ABMSInit and the position of the cursor (5403) is put in agreement with the action carried out and at the end of processing the application returns to Windows the message "WM_ENTERIDLE", referenced 541, which thus replaces the message "WM_SYSCOMMAND"
  • the GetMsgHook filter filters the messages "WM__NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WMJ ⁇ YDOWN, WM_SYSKEYDOWN".
  • WM_NCLBUTTONDOWN arrives at the ABMS application, we look by the instruction referenced 504 if it is a menu sequence or not. If it is not a menu sequence, we look if we are working for an icon with the reference 500. If we are not working for an icon, we look if the parameters have been initialized by the ABMSHitTest ( 501).
  • the program checks whether the object is not iconic by the reference (510), appendix 1, in the case where it is not iconic, the instruction (515) see if the direction variables have been initialized and in this case launch the ABMSMove (511) function, appendix 5, otherwise the ABMSDirection (512) function, appendix 6, is launched to initialize the direction variables with the parameters result of the function ABMSTestDirect (513), appendix 8.
  • the sequence launches by the instruction referenced (5111) the loading of the icon at the position indicated by the cursor and the function ABMSLoadlcon (5100). Then, the sequence returns control to Windows by sending the message "WM_ENTERIDLE".
  • the application begins at reference 534 by treating the case of the abortion keys constituted by the escape (VK-ESCAPE) and return keys trolley (VK-RETURN). If we are not in this case and the application has received for example the message VK_Left, the application first looks by the sequence referenced 530 if we are iconic, and loads the icon by the ABMSLoadlcon (5100) function, then look at the instruction (5301) if the parameters W_Caption, W_Left, W_Right have been initialized and in this case, moves the icon or gives the actual magnitude to it by the sequence (5302).

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Digital Computer Display Output (AREA)
  • User Interface Of Digital Computer (AREA)
  • Image Generation (AREA)
  • Controls And Circuits For Display Device (AREA)

Abstract

Procédé de retaillage ou de déplacement de fenêtres dans une application 'Windows'R, caractérisé en ce qu'il consiste à interposer entre 'Windows'R (1) et les différentes applications (20, 21, 22) tournant sous 'Windows'R des filtres (4) interceptant des messages particuliers, à traiter par une application spécifique (5) ces messages et à renvoyer à 'Windows'R un message neutre 'WM-ENTERIDLE' qui ne provoque aucune action de la part de 'Windows'R et ne bloque pas le fonctionnement des autres applications.

Description

PROCEDE DE RETAILLAGE OU DE DEPLACEMENT DE FENETRES.
L'invention concerne un procédé de retaillage ou de déplacement de fenêtres.
Un procédé de retaillage ou de déplacement de fenêtre est connu, notamment par le logiciel multitâches multifenêtres "Windows" de Microsoft. Ce type de logiciel présente l'inconvénient dans le cas du retaillage ou du déplacement d'une fenêtre de bloquer l'évolution des applications qui tournent dans les autres fenêtres.
La présente invention a pour but de pallier cet inconvénient.
Ce but est atteint par le fait que le procédé de retaillage ou de déplacement de fenêtres dans une application "Windows" consiste à interposer entre "Windows" et les différentes applications tournant sous "Windows" des filtres interceptant des messages particuliers, à traiter par une application spécifique ces messages et à renvoyer à "Windows" un message neutre qui ne provoque aucune action de la part de "Windows" et ne bloque pas le fonctionnement des autres applications.
Selon une autre particularité, le traitement effectué par l'application spécifique consiste à traiter chacun des événements particuliers pouvant intervenir et correspondant potentiellement à un événement de déplacement de la fenêtre ou de retaillage d'une fenêtre, et au cours de ce traitement à faire appel à des fonctions spécifiques permettant d'une part d'initialiser un certain nombre de paramètres W_Top, W_Right, W_Bottom, W_Left, W_Caption, Frm_CurPos, h_WndCurr conservés jusqu'à l'occurence d'un événement ultérieur qui provoquera la fin du traitement.
Selon une autre particularité, les paramètres conservés sont constitués par :
- "h_WndCurr" = "h_WndCurrent, qui est une variable permettant de savoir qu'une action a été engagée sur une fenêtre quelconque ;
- "b_LoadedIcon, pour mémoriser qu'une icône a été chargée ;
"h_WndMenu", qui est la variable permettant de savoir, dans le cas d'une icône, si on est dans une phase de déroulement de menu ou de déplacement d'icône ;
- "h-OldCursor", qui est la variable permettant de mémoriser un identifieur du curseur actif de Windows avant le lancement de l'application et le remplacement par le curseur spécifique de l'application
- "w_CXScreen", "w_CYScreen", "w_CXframe", "w_CYMinHeigth", "w_CXMinWidth", qui sont respectivement les variables de coordonnées de la fenêtre en cours de retaillage, de cadre et de largeur mimimum ;
"Frm_CurPos", qui est la variable de position courante du cadre ;
"Mse_CurPos", qui est la variable de position courante de la souris ;
"w_Left", "w_Top", "w_Right", "w_Bottom", "w_Caption", qui sont les variables de direction utilisées dans le calcul des coordonnées de la nouvelle fenêtre et les tests de direction ;
- "Wnd_StartPos", qui est la variable de définition de la position initiale de la fenêtre ;
- "Mse_StartPos", qui est la variable de définition de la position initiale du curseur ;
- "b_Cursor" et "b_LoadedIcon", qui sont des variables booléennes supposées fausses au départ.
Selon une autre particularité, les filtres sont en nombre de 2. Un premier "WM_GETMESSAGE" permettant de recevoir les messages postés par les interruptions hardware, tels que :
- WM_NCLBUTTONDOWN - WM_MOUSEMOVE
- WM_KEYDOWN
- WM_SYSKEYDOWN
et un deuxième filtre "WH_CALLWNDPROC" permettant de filtrer et de recevoir les messages envoyés à la méthode, tels que :
- WM_SYSCOMMAND
- WM_ACTIVATEAPP
- WM_NCACTIVATE
- WM_ACTIVATE.
Selon une autre particularité, l'interception d'un message déclenche le traitement d'un programme spécifique à chaque message et fait intervenir les paramètres conservés et des fonctions principales de traitement, telles que :
- ABMSInit pour initialiser un traitement,
- ABMSMove pour effectuer le déplacement de la fenêtre, et
- ABMSEnd pour terminer un traitement,
qui elles-mêmes font appel à des fonctions utilitaires.
Selon une autre particularité, la fonction ABMSInit est mise en oeuvre uniquement pour le traitement des messages "WM_NCLBUTTONDOWN" et "SC_SIZE" qui est un message dépendant de "WM_SYSCOMMAND" .
Selon une autre particularité, la fonction ABMSEnd est mise en oeuvre uniquement pour le traitement des messages "WM_LBUTTONUP" et "VK_ESCAPE", VK-RETURN" qui dépendent de "WM_SYSKEYDOWN" .
Selon une autre particularité, la fonction ABMSMove est mise en oeuvre uniquement pour le traitement des messages "WM_MOUSEMOVE, MK_LEFT, VK_UP, VK_RIGHT et VK_DOWN" qui sont des messages dépendant de "WM_SYSKEYDOWN" .
Selon une autre particularité, la fonction ABMSInit consiste à approprier les messages souris par l'instruction "SETCAPTURE", puis à regarder si la fenêtre est une fenêtre fille d'une fenêtre mère, c'est-à-dire inscrite dans la fenêtre mère pour limiter les mouvements de la fenêtre fille, puis à initialiser les coordonnées initiales de la fenêtre et la position du curseur pour devenir les coordonnées courantes et à initialiser les paramètres caractéristiques de la fenêtre (w_CXframe, w_CXMinWidth, w_CYMinHeigth).
Selon une autre particularité, le procédé comprend les étapes suivantes :
- passage en mode actif des filtres ;
- mémorisation de l'identifieur de la fenêtre "h_Wnd", destinataire du message ; - mémorisation du type d'action résultant de la zone de clic, cette mémorisation se faisant par la fonction HitTest et la fonction ABMSInit ;
- appropriation des messages souris ultérieurs pour le compte de la fenêtre en cause ;
- premier dessin du cadre fantôme autour de la fenêtre par la procédure InvertBlock ; neutralisation du message par remplacement et substitution d'un message "WM_ENTERIDLE" qui n'est pas traité et ne provoque aucune action de la part de Windows.
Selon une autre particularité, le procédé comprend les étapes suivantes :
- calcul des coordonnées finales de la fenêtre par la procédure ABMSComputNewPos, effacement du fantôme par InvertBlock ;
- dessin de la fenêtre en position finale par la fonction ABMSMove ;
- remise à 0 des paramètres de mémorisation par la fonction ABMSEnd.
Selon une dernière particularité, le procédé comprend en outre les étapes suivantes : abandon de la propriété des messages souris par l'instruction "Release Capture" ; - passage du filtre en mode passant.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence aux dessins annexés dans lesquels :
- la figure 1 représente le chemin de principe général de l'invention ; - la figure 2 représente le principe de fonctionnement des filtres de l'invention ;
- la figure 3 représente un tableau des scénarii possibles ;
- la figure 4 représente l'organigramme de fonctionnement du programme d'interprétation suite à la mise en place de la fonction de filtrage ; - la figure 5 représente l'art antérieur à l'invention.
- les annexes 1 à 8 représentent le détail des différentes étapes représentées dans l'organigramme de la figure 4 ;
L' invention concerne un perfectionnement à un logiciel multitâches et multifenêtres fonctionnant sur un matériel informatique comportant une unité centrale de traitement ou processeur, un moniteur d'affichage, une ressource clavier et une souris.
Dans l'art antérieur de la figure 5, représentant le fonctionnement d'un logiciel permettant le déroulement de plusieurs applications avec, pour chaque application, une ou plusieurs fenêtres, on peut constater un certain nombre d'inconvénients. Ainsi, dans un environnement "Windows" ou OS2, le noyau (1) du logiciel "Windows" émet des messages (30, 31) en direction des différentes applications ou tâches (T1, T2, T3) , respectivement (20, 21, 23). Le noyau (1) de "Windows" permet d'adresser des messages (30, 31) aux tâches activées, par exemple dans le cas de la figure 5 les tâches (T1) et (T3), et d'empiler ces messages adressés à la tâche respective dans une file d'attente respective
(Q1, Q3). Le noyau (1) de "Windows" attribue le processeur de traitement à l'application qui va venir gérer les messages de la file et les traiter, et lorsque la file est épuisée, la tâche rend le processeur au noyau (1) de "Windows" pour permettre l'attribution du processeur à une autre application activée. Chaque application (T1, T3) comporte une fenêtre associée (F1, F3). Chaque fenêtre constitue un objet visible ou non. A chaque fenêtre est associée une méthode qui constitue le mode d'emploi ou de réaction de la fenêtre aux divers messages qui concernent la fenêtre de l'application. Cette méthode est un programme qui traite chacun des messages et réalise des actions en conséquences. Ce programme peut choisir de traiter certains de ces messages ou de laisser traiter certains autres par "Windows". Dans ce dernier cas, le programme de l'application prévoit l'envoi d'un message (32) vers une fonction (13) du noyau (1) de "Windows", fonction qui est appelée "default Windows Proc". Le noyau (1) de "Windows" sait reconnaître ces messages particuliers et effectue, par exemple dans le cas du retaillage d'une fenêtre ou du déplacement de celle-ci un traitement standard. Ainsi, un opérateur qui veut retailler une fenêtre, va agir sur la "souris" du système qui génère par les interruptions du Hardware un certain nombre de messages. Ces messages vont être envoyés et empilés dans la file, par exemple (Q1) , de l'application concernée. Le programme, lors du traitement de la file, passe ces messages à la méthode de la fenêtre qui cherche à savoir où se trouve la souris, c'est-à-dire si elle se trouve sur un bord, au milieu, ou sur une zone menu de la fenêtre. En fonction de cet endroit, la méthode génère un certain nombre de messages distincts.
Si la souris est sur un bord de la fenêtre, l'interruption qui en résulte génère le message "WM_LBUTTONDOWN" . Lorsque la méthode récupère ce message, elle l'envoie à la fonction (13) "Def Window Proc" et rend la main à "Windows". "Windows", détectant ce message particulier, s'enquiert de savoir sur quelle zone de la fenêtre il a été obtenu, et selon le cas, génère un certain nombre de messages, tels que "WM_SIZE" (correspondant à un retaillage de la fenêtre) ou "WM_MOVE" (correspondant à un déplacement de la fenêtre) et se met en attente des messages suivants provenant de la souris de façon à pouvoir les traiter immédiatement.
Les messages (30, 31) envoyés peuvent être soit des messages système envoyés par le noyau (1) de "Windows" directement à une application, soit des messages provenant du Hardware, souvent après une interruption, par exemple messages souris ou messages clavier. Lorsque la méthode a envoyé un message à la fonction "Def Wnd Proc", et tant que les autres informations concernant le retaillage ou le déplacement de la fenêtre permettant à la fonction (13) de terminer le traitement du message ne sont pas parvenues à cette fonction, le processeur continue d'exécuter cette fonction, n'en sort plus et il se met à attendre les autres messages. Ceci a pour inconvénient de bloquer le processus de traitement des autres tâches. Cet inconvénient est particulièrement gênant pour des applications temps réel, par exemple, de surveillance en temps réel ou de pilotage d'alarme. Dans ce type d'application, il peut arriver qu'une manoeuvre de retaillage ou de déplacement de fenêtre par clavier soit lancée et que l'opérateur dérangé bloque toutes les autres applications pendant tout le temps où il n'a pas eu la possibilité de terminer son action de taillage ou de déplacement d'une fenêtre, en intervenant sur le clavier ou sur la souris.
L'invention vise donc à éliminer cet inconvénient et propose l'architecture de la figure 1 dans laquelle, entre les différentes applications (20, 21, 22) et le noyau (1) de "Windows", est placé un filtre (4), accroché au noyau "Windows", lequel lors du passage de certains messages va assurer le traitement de ces messages par une application ABMS (5) . Ainsi, les messages (301, 321, 331) envoyés par le noyau "Windows" vers les applications A, B, C (20, 21, 22) passent dans le filtre (4), et selon l'activation ou la non-activation sont transmis ou traités par ABMS. Dans le cas de l'activation du filtre, certains types de messages sont transmis sous forme de messages (304) à l'application A, (324) à l'application B et (314) à l'application C. Dans le cas où l'un des messages (301, 321, 313) correspond à un événement spécifique (50, 51, 52, 53), comme représenté aux figures 2 et 4, ce message est intercepté et traité par l'application ABMS (5), comme on va le voir par la suite.
L'invention repose donc sur l'utilisation des filtres de message fournis par Windows, ces filtres permettant à une application quelconque d'être informée du passage de tous les messages correspondant à un type d'événement particulier et de les modifier ou les substituer avant qu' ils ne parviennent à leur véritable destinataire. L'application ABMS (5) utilise donc deux de ces filtres spécifiques. Deux filtres sont nécessaires pour couvrir tous les messages possibles dans les cas qui nous intéressent, parce que Windows classe tous les messages par familles de messages et les messages qui nous intéressent appartiennent à deux de ces familles. Un filtre "WM_GETMESSAGE" (400, Annexe 1) permet de recevoir les messages postés par les interruptions hardware, c'est-à- dire la souris ou le clavier, messages qui auraient été normalement déposés dans la queue de l'application. Un autre filtre "WH_CALLWNDPROC" (401, annexe 1) permet de filtrer et de recevoir tous les messages qui seraient envoyés directement à la méthode de l'application. Ces filtres sont installés lors de l'initialisation de l'application ABMS, cette installation étant représentée par la référence (40) à la figure 2 et à l'annexe 1, et s'effectuant par la fonction "SETWINDOWSHOOK" . La clôture de l'application ABMS retire les filtres, ce retrait étant représenté par la référence (41) à la figure 2 et à l'annexe 1 et effectué par la fonction "UNHOOKWINDOWSHOOK" . Ces filtres installés peuvent être passants, c'est-à-dire n'affectant pas les messages ou actifs, c'est-à-dire provoquant un traitement particulier survenant d'un certain événement spécifique. Dans le cas où le filtre est passant, les messages (301, 321, 311) arrivant dans le filtre seront transmis aux applications sous forme de message distribué (304, 324, 314), et dans le cas où le filtre est actif, il enverra le message à l'application ABMS pour traitement. Les options prises en compte par l'application ABMS peuvent être décomposées en divers scénarii qui sont classés dans un tableau à trois dimensions (cf figure 3) représentant les actions, les moyens utilisés et les états de la fenêtre manipulée. La réalisation de l'application ABMS a nécessité la solution d'un certain nombre de difficultés, certaines générales et rappelées par la suite, d'autres spécifiques d'un scénario et indiquées dans la case correspondante de la figure 3 .
Les difficultés générales concernent la terminaison de l'action lors de l'annulation par la touche ESC. A ce moment, la restauration de l'état initial suppose la mémorisation d'un certain nombre d'informations constituées par des variables rémanentes dans la zone de données de l'application ABMS. Une autre difficulté est l'interpénétration des scénarii clavier/souris. En effet, la frontière entre le scénario clavier et souris n'est pas étanche, une action de reprise avec l'un de ces moyens peut être poursuivie avec l'autre à tout instant. ABMS prend en compte cette souplesse. Chaque message traité fait évoluer le contexte général de l'application en modifiant le contenu des variables ou en jouant sur des paramètres définis dans la zone de données d'ABMS, et laisse les variables dans un état clairement défini susceptible d'être repris pas n'importe quel autre message. Ces variables sont représentées par :
- "h_WndCurr", qui est une variable permettant de savoir qu'une action a été entamée sur une fenêtre ;
"hJWndMenu", qui est la variable permettant de savoir, dans le cas d'une icône, si on est dans une phase de déroulement de menu ou de déplacement d' icône ;
- "h_01dCursor", qui est la variable permettant de mémoriser un identifieur du curseur actif de Windows avant le lancement de l'application et le remplacement par le curseur spécifique de l'application
"w_CXScreen", "w_CYScreen", "w_CXframe", nw_CYMinHeigth", "w_CXMinWidth", qui sont respectivement les variables de coordonnees de la fenêtre en cours de retaillage, de cadre et de largeur mimimum ;
"Frm_CurPos", qui est la variable de position courante du cadre ;
- "Mse_CurPos", qui est la variable de position courante de la souris ;
•w_Left", "w_Top", "w_Right", "w_Bottom", "w_Caption", qui sont les variables de direction utilisées dans le calcul des coordonnées de la nouvelle fenêtre et les tests de direction ;
- "Wnd_StartPos", qui est la variable de définition de la position initiale de la fenêtre ;
- "Mse_StartPos", qui est la variable de définition de la position initiale du curseur ;
- "b_Cursor" et "b_LoadedIcon", qui sont des variables booléennes supposées fausses au départ.
Dans le cas du retaillage d'une fenêtre qui n'est pas une icône effectué uniquement par la souris, l'opérateur doit effectuer les opérations suivantes : - il positionne le curseur de la souris sur un des bords de la fenêtre, appuie sur le bouton gauche et le maintien enfoncé. Il déplace ensuite la souris, ce qui a pour effet de déplacer sur l'écran un des bords du cadre représentant le fantôme de la fenêtre. Lorsque l'utilisateur estime avoir atteint la taille désirée, il relâche le bouton gauche et la fenêtre se redessine dans le cadre qui vient d'être redéfini. Au début de l'opération, le filtre installé par ABMS est initiallement dans l'état passant. Tous les messages de déplacement de la souris émis par le noyau (1) de "Windows" sont distribués. Lorsque l'opérateur appuie sur le bouton gauche de la souris, le curseur se trouvant sur le bord de la fenêtre, "Windows" génère un message "WM_NCLBUTTONDOWN" dont les paramètres contiennent l'identifieur de la fenêtre et une valeur définissant la zone sur laquelle l'événement s'est produit. Les actions de ABMS sont alors les suivantes :
- passage en mode actif, mémorisation de l'identifieur de la fenêtre HWND, destinataire du message et des coordonnées initiales ;
- mémorisation du type d'action résultant de la zone de clic (retaillages gauche, droit, haut, bas, diagonale) ; cette mémorisation se fait par la portion de programme ABMSHit TEST, portant la référence (501) sur les annexes 1 et 7, et par le programme ABMSInit, portant les références (502, 503) sur l'annexe 3 ;
- appropriation des messages souris ultérieurs (par l'instruction SETCAPTURE) pour le compte de la fenêtre en cause ;
- premier dessin du cadre fantôme autour de la fenêtre par la procédure ABMSInvertBlock, représentée à l'annexe 4 par la référence (521), qui à chaque mouvement annule le cadre fantôme précédent et redessine le suivant au nouvel emplacement ;
- neutralisation du message par remplacement et substitution d'un message "WM_ENTERIDLE" qui n'est pas traité et ne provoque aucune action de la part de Windows.
Lorsque le programme ABMS est lancé, une première fonction, représentée à l'annexe 1 par la référence (40), installe ou désinstalle la fonction filtre. L'installation de la fonction filtre se fait par la fonction "SETWINDOWSHOOK", et. la désinstallation se fait par la fonction "UNHOOKWINDOWSHOOK", comme représenté sur la figure 2 par les références (40, 41). Une fois cette fonction filtre activée, tous les messages tels que "WM_SYSCOMMAND, WM_LBUTTONUP, WM_SYSKEYDOWN,WM_NCLBUTTONDOWN, WM_MOUSEMOVE" sont détournés, traités par le programme ABMSHook et neutralisés par envoi du message "WM_ENTERIDLE" de l'application à "Windows". Tous ces messages sont au départ émis par "Windows" à la suite d'une interruption clavier ou souris.
Ainsi, comme représenté à la figure 4, lorsque le message "WM_NCLBUTTONDOWN", référencé (50), est émis par "Windows", celui-ci est intercepté par le programme ABMSHook qui mémorise dans un premier temps (504) l'identifieur de la fenêtre, destinataire du message dans la variable "h_WndCurr", effectue un test pour savoir si la fenêtre est une icône, ce test étant indiqué dans le programme (50) de l'annexe 1 par la ligne (500), mémorise le type d'action résultant de la zone de cliquage par la portion de programme ABMSHit Test (501), de l'annexe 1, représenté en détail à l'annexe 7 par la référence (501), et lance le sous-programme ABMSInit (502, 503), de l'annexe 1, représenté en détail par les références (502, 503) à l'annexe 4. Ce programme approprie les messages souris ultérieurs par le message "SETCAPTURE" pour le compte de la fenêtre en cause et détermine les coordonnées initiales de la fenêtre et de la position du curseur. La séquence (50) de traitement de "WM_NCLBUTTONDOWN" renvoie à la fin du traitement le message "WM_ENTERIDLE" .
Le message suivant, envoyé par Windows, peut être un mouvement de la souris, signalé par le message "WM_MOUSE
MOVE" et traité par la séquence d'instruction (51) de l'annexe 1 à la fin de laquelle le programme rend la main à
Windows par l'envoi du message "WM_ENTERIDLE" . L'autre possibilité d'instruction est une instruction de relâchement du bouton de la souris, cette instruction étant signalée par le message Windows "WM_LBUTTONUP", dont la séquence de traitement (52) est représentée à l'annexe 1.
Cette séquence lance le sous-programme ABMSEnd qui à la fin rend la main au noyau (1) de Windows pour l'envoi du message "WMJENTERIDLE" .
Dans le cas d'un message "WM_MOUSEMOVE" envoyé par Windows, le programme regarde si l'objet n'est pas iconique par la référence (510), annexe 1 ; dans le cas où il n'est pas inconique, l'instruction (515) regarde si les variables de direction ont été initialisées et dans ce cas lance la fonction ABMSMove (511) annexe 5, sinon la fonction ABMSDirection (512), annexe 6, est lancée pour initialiser les variables de direction avec comme paramètres le résultat de la fonction ABMSTestDirect (513), annexe 8. Dans le cas où l'objet est iconique, la séquence lance par l'instruction référencée (5111) le chargement de l'icône à la position indiquée par le curseur et la fonction ABMSLoadlcon (5100). Ensuite, la séquence rend la main à Windows en envoyant le message "WM_ENTERIDLE" . Lorsque ABMS intercepte un message "WM_SYSKEYDOWN", représenté par la référence (53) à la figure 4, le traitement d'un tel message met en oeuvre le sous-programme
(53) qui commence par traiter le cas de l'actionnement d'une touche de retour chariot lors de la réception d'un message "VK_RETURN" ou d'échappement représenté par un message "VK_ESCAPE", et ensuite traite le cas des touches de déplacement à gauche "VK_LEFT", vers le haut "VK_UP", à droite "VK_RIGHT", vers le bas "VK_DOWN" . Selon le type de touche enfoncée, il effectue le traitement correspondant à un des sous-programmes (530) pour le déplacement à gauche, (531) pour le déplacement vers le haut, (532) pour le déplacement à droite, (533) pour le déplacement vers le bas. Comme on l'a expliqué ci-dessus, dès qu'un message est reçu par le filtre, celui-ci est traité, et le programme ABMS, après le traitement correspondant, rend la main au noyau (1) de Windows qui peut ainsi redonner la main à une autre application en attendant que le filtre intercepte un nouveau message dont le traitement nécessite l'intervention du programme ABMS. Le filtre reste actif jusqu'à ce que l'opérateur relâche le bouton gauche de la souris ou tape "Enter" ou "Esc". Cette action génère un message "WM_LBUTTONUP, WM_SYSKEYDOWN, VK_ENTER, VK_ESCAPE" qui prévoit le changement d'état du filtre ABMS de l'état actif à l'état passant. Les actions effectuées au cours de ce changement sont les suivantes : calcul des coordonnées finales de la fenêtre par la procédure ABMSComputNewPos, représentée par le sous- programme (5210) de l'annexe 6 ;
- effacement du fantôme par InvertBlock ;
- dessin de la fenêtre en position finale ; - remise à zéro des paramètres mémorisés ;
- abandon de la propriété des messages souris par l'instruction "Release Capture" ; - passage du filtre en mode passant.
Comme on vient de l'expliquer, l'application ABMS, grâce au filtre installé, reçoit les différents messages "WM_SYSCOMMAND, WM_NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WM_SYSKEYDOWN, WM_KEYDOWN, WM_ACTIVATEAPP, WM_NCACTIVATE, WM_ACTIVATE" . Cette application substitue à ces messages, à l'intention de Windows, un message neutre tel que "WM_ENTERIDLE" et ensuite procède au traitement de ces messages en faisant appel à différentes fonctions principales de traitement appelées lorsque l'on détecte qu'un traitement est initialisé. Ces fonctions principales de traitement sont :
- la fonction ABMSInit pour initialiser un traitement lors de la réception, par exemple d'un premier "SC_MOVE" ou d'un "SC_SIZE" dans un "WM_SYSCOMMAND" ;
Cette fonction ABMSInit consiste à approprier les messages souris par l'instruction "SETCAPTURE", puis à regarder si la fenêtre est une fenêtre fille d'une fenêtre mère, c'est- à-dire inscrite dans la fenêtre mère pour limiter les mouvements de la fenêtre fille, puis à initialiser les coordonnées initiales de la fenêtre et la position du curseur pour devenir les coordonnées courantes et à initialiser les paramètres caractéristiques de la fenêtre (w_CXFrame, w_CXMinWidth, w_CYMinHeight).
- puis la fonction ABMSEnd et la fonction ABMSMove,
En plus de ces trois fonctions principales, il y a des fonctions utilitaires appelées en différents endroits des fonctions principales et qui servent à effectuer les traitements utilitaires. Ces fonctions sont :
- la fonction ABMSComputNewPos qui sert, lorsqu'on lui donne les coordonnées de la souris, à calculer et mettre à jour les coordonnées de la fenêtre en tenant compte des variables globales et rémanentes. Cette fonction ABMSComputNewPos (5210), annexe 5, permet de calculer les nouvelles positions à partir des paramètres W_left, W_Caption, W_Top, W_Right, W_Bottom et les coordonnées de la souris et du cadre de la fenêtre, ainsi qu'à partir des coordonnées minimales en hauteur et en largeur des fenêtres. Elle teste aussi les limites de ces calculs pour s'assurer qu'une fenêtre fille ne sort pas d'une fenêtre mère.
- la fonction ABMSDirection (512), annexe 6, sert à déterminer la forme du curseur et à initialiser les variables de direction en fonction des messages reçus. Cette fonction ABMSDirection (512), annexe 6, par exemple dans le cas où le paramètre renvoyé par ABMSTestDirection est D_Top, positionne le paramètre W_Top à 1 et accroche la position du curseur au bord supérieur de la fenêtre par l'instruction référencée (5120), ensuite la séquence effectue un test sur le paramètre W_Left pour savoir si W_Left est initialisé et dans le cas affirmatif, envoie le message "D_TTOBDBLEARROW" pour demander l'affichage du curseur incliné à 45° vers le haut et la droite. Si W_Left n'est pas initialisé, la séquence regarde si W_Right est initialisé et dans ce cas envoie le message "D_BTOTDBLEARROW" pour demander l'affichage du curseur incliné vers le haut et la gauche, et dans le cas où le test sur W_Right est négatif, un curseur vertical est affiché par l'exécution du message "D-VERTDBLEARROW" . la fonction ABMSHitTest (501) , annexe 7, sert à déterminer à l'initialisation dans quelle zone on a cliqué pour initialiser, dans le cas des mouvements souris, les variables de direction. Cette fonction est appelée par ABMSInit dans le cas où on reçoit un "WM_NCLBUTTONDOWN" et permet d' initialiser les variables W_Top, W_Right, W_Bottom, W_Left et W_Caption.
Ainsi, comme on peut le voir à l'annexe 7 lorsque l'on reçoit un message HT_ToρRight, qui indique que le coin haut droit a été cliqué par la souris, la fonction ABMSHitTest met à 1 les variables W_Toρ et W_Right qui permettront par la suite, lors de la réception d'un nouveau message de savoir qu'il y a eu une initialisation dans le coin haut droit de la fenêtre, et que par conséquent, on doit traiter le déplacement de la fenêtre ou le retaillage de celle-ci. - la fonction ABMSInvertBlock, représentée par la référence (5030), annexe 7, effectue le dessin du rectangle en dessinant quatre rectangles adjacents commandés par la fonction PatBlt, en fonction des paramètres hDC et des dimensions de la fenêtre représentée par exemple par P_RecFrm.left. Cette fonction PatBlt effectue en même temps par la commande DSTINVERT l'inversion du fantôme de la fenêtre.
- la fonction ABMSLoadCursor (5031), annexe 7, qui charge le curseur en fonction des paramètres envoyés qui dépendent de la position sur le bord de la fenêtre ; ainsi, si les paramètres W_Left et W_Top sont initialisés à 1, on a affaire au bord gauche haut de la fenêtre, et le curseur initialisé aura une allure de flèche orientée vers le bord droit inférieur de la fenêtre, c'est-à-dire à 45º. - la fonction ABMSLoadlcon (5100), annexe 8, qui permet lorsque l'on déplace une icône statique de remplacer le curseur par l'image de l'icône statique générée par Windows, et dans le cas où on déplace une icône dynamique de remplacer cette image d' icône dynamique par une image constituée par le curseur.
- la fonction ABMSTestDirect, représentée à la référence (513) de l'annexe 8, permet de déterminer le paramètre à renvoyer, par exemple D_Left (5130), en effectuant un test sur l'information reçue par l'application et envoyée par Windows, constituée par la coordonnée en X de la position de la souris représentée par P_MSEPOS.X et de comparer cette coordonnée à la valeur de la position gauche de la fenêtre, et dans le cas où la valeur de la coordonnée en X de la souris est inférieure à l'abscisse du bord gauche de la fenêtre, cette fonction retourne le message D_Left à l'application. Cette fonction est utilisée en conjonction avec la fonction ABMSDirection. - la fonction ABMSMove (511), annexe 5, permet d'effectuer le mouvement de la fenêtre en inversant le fantôme de la fenêtre par la fonction ABMSInvertBlock, représentée par la référence (5030) aux annexes 5 et 7, puis ensuite de calculer la nouvelle position de la fenêtre par la fonction ABMSComputNewPos (5210), et enfin d'inverser le fantôme de la fenêtre pour la nouvelle position calculée, représentée par la référence (5112).
- la fonction ABMSEnd (521), annexe 4, termine le processus en regardant par l'instruction (5211) si la fenêtre est iconique. Si elle n'est pas iconique, on termine par une fin normale (5212), c'est-à-dire en lançant la fonction ABMSComputNewPos (5210), sinon le curseur reprend par l'instruction (5213) la position initiale qu'il avait au départ. Cette fonction permet également par la séquence (5214) de déterminer si la fenêtre en traitement est une fenêtre fille et dans ce cas de convertir les coordonnées avant un mouvement. De même cette fonction, si nécessaire, restaure par la séquence (5215) le curseur et remet par la séquence (5216) les paramètres à 0. L'application par le filtre CalMsgHook permet de filtrer et recevoir les messages qui auraient été envoyés directement à la méthode de l'application, entre autres les messages "WM_SYSCOMMAND, WM_ACTIVATEAPP,WM_NCACTIVATE, WM_ACTIVATE" . Le traitement du message "WM_SYSCOMMAND", représenté en (54), peut se décomposer en un traitement, soit d'un message "SC_MOVE", soit d'un message ",SC_SIZE". Le message "SC_SIZE" positionne les paramètres W_Caption à 1, et le message de retaillage de fenêtre "SC_SIZE" provoque le traitement représenté par la référence (540). Lorsque l'application reçoit un message de retaillage de la fenêtre, elle demande (5401) la position du curseur en imposant que celle-ci soit celle de la souris. Ensuite, cette procédure lance en (5402) la fonction ABMSInit et la position du curseur (5403) est mise en accord avec l'action effectuée et en fin de traitement l'application renvoie à Windows le message "WM_ENTERIDLE", référencé 541, qui se substitue ainsi au message "WM_SYSCOMMAND"
De même, le filtre GetMsgHook filtre les messages "WM__NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WMJŒYDOWN, WM_SYSKEYDOWN" . Lorsqu'un tel message "WM_NCLBUTTONDOWN" arrive à l'application ABMS, on regarde par l'instruction référencée 504 s'il s'agit d'un déroulement de menu ou non. S'il ne s'agit pas d'un déroulement de menu, on regarde si on travaille pour une icône par la référence 500. Si on ne travaille pas pour une icône, on regarde si les paramètres ont été initialisés par la fonction ABMSHitTest (501). Si les paramètres n'ont pas été initialisés, on lance la fonction ABMSInit (502, 503) en rangeant dans le point les coordonnées en X et en Y fournies par le paramètre message, et ensuite on envoie à Windows le message "WM_ENTERIDLE" (505) pour lui rendre la main. Dans le cas d'un message "WM_MOUSEMOVE" envoyé par Windows, le programme regarde si l'objet n'est pas iconique par la référence (510), annexe 1, dans le cas où il n'est pas iconique, l'instruction (515) regarde si les variables de direction ont été initialisées et dans ce cas lance la fonction ABMSMove (511), annexe 5, sinon la fonction ABMSDirection (512), annexe 6, est lancée pour initialiser les variables de direction avec comme paramètres le résultat de la fonction ABMSTestDirect (513), annexe 8. Dans le cas où l'objet est iconique, la séquence lance par l'instruction référencée (5111) le chargement de l'icône à la position indiquée par le curseur et la fonction ABMSLoadlcon (5100). Ensuite, la séquence rend la main à Windows en envoyant le message "WM_ENTERIDLE" .
Dans le cas où l'on reçoit le message "WM_LBUTTONUP" (52) de l'application, on regarde si l'opérateur a effectué un déroulement de menu par la référence (520), sinon l'application regarde si la coordonnée de la fenêtre correspond à celle de la souris et lance la fonction ABMSEnd (521) pour ensuite envoyer à Windows le message "WM_ENTERIDLE" .
Dans le cas des messages envoyés à la suite de l'actionnement d'une touche, l'application commence à la référence 534 par traiter le cas des touches d'avortement constituées par les touches d'échappement (VK-ESCAPE) et de retour chariot (VK-RETURN). Si on n'est pas dans ce cas là et que l'application a reçu par exemple le message VK_Left, l'application regarde tout d'abord par la séquence référencée 530 si l'on est iconique, et charge l'icône par la fonction ABMSLoadlcon (5100), regarde ensuite par l'instruction (5301) si les paramètres W_Caption, W_Left, W_Right ont été initialisés et dans ce cas, déplace l'icône ou donne la grandeur réelle à celle-ci par la séquence (5302). Dans le cas où on n'est pas iconique à ce momentlà, on lance la fonction ABMSMove et on donne à la position du curseur la position de la souris. Autrement, ABMS lance la fonction ABMSDirection et ensuite renvoie à Windows le message "WM_ENTERIDLE" . Le fonctionnement des autres parties du programme traitant les différents événements pouvant intervenir et faisant appel aux fonctions de traitement principales ou aux fonctions utilitaires peut être déduit des explications cidessus et du listing figurant dans les annexes.
Toute modification à la jrtée de l'homme de métier fait également partie de l'esprit de l'invention.
Figure imgf000024_0001
Figure imgf000025_0001
Figure imgf000026_0001
Figure imgf000027_0001
Figure imgf000028_0001
Figure imgf000029_0001
Figure imgf000030_0001
Figure imgf000031_0001
Figure imgf000032_0001
Figure imgf000033_0001

Claims

REVENDICATIONS
1. Procédé de retaillage ou de déplacement de fenêtres dans une application "Windows", caractérisé en ce qu'il consiste à interposer entre "Windows" (1) et les différentes applications {20, 21, 22) tournant sous "Windows" des filtres (4) interceptant des messages particuliers, à traiter par une application spécifique (5) ces messages et à renvoyer à "Windows" un message neutre "WM-ENTERIDLE" qui ne provoque aucune action de la part de "Windows" et ne bloque pas le fonctionnement des autres applications.
2. Procédé selon la revendication 1, caractérisé en ce que le traitement effectué par l'application spécifique consiste à traiter chacun des événements particuliers pouvant intervenir et correspondant potentiellement à un événement de déplacement de la fenêtre ou de retaillage d'une fenêtre, et au cours de ce traitement à faire appel à des fonctions spécifiques permettant d'une part d'initialiser un certain nombre de paramètres "w_Top, w_Right, w_Bottom, w_Caption, FrmCurPos, h_WndCurr" conservés jusqu'à l'occurence d'un événement ultérieur qui provoquera la fin du traitement.
3. Procédé selon la revendication 2, caractérisé en ce que les paramètres conservés sont constitués par :
- "h_WndCurr", qui est une variable permettant de savoir qu'une action a été entamée sur une fenêtre ;
- "b_Loaded!ron", pour mémoriser qu'une icône a été chargée ;
"h_WndMenu", qui est la variable permettant de savoir, dans le cas d'une icône, si on est dans une phase de déroulement de menu ou de déplacement d'icône ;
- "h-OldCurser" , qui est la variable permettant de mémoriser un identifieur du curseur actif de Windows avant le lancement de l'application et le remplacement par le curseur spécifique de l'application ; "w_CXScreen", "w_CYScreen", "w_CXframe", "w_CYMinHeigth" , "w_CXMinWidth" , qui sont respectivement les variables de coordonnées de la fenêtre en cours de retaillage, de cadre et de largeur mimimum ;
- "Frm_CurPos" , qui est la variable de position courante du cadre ;
"Mse_CurPos" , qui est la variable de position courante de la souris ;
"w_Left", "w_Top", "w_Right", "w_Bottom", "w_Caption" , qui sont les variables de direction utilisées dans le calcul des coordonnées de la nouvelle fenêtre et les tests de direction ;
- "Wnd_StartPos" , qui est la variable de définition de la position initiale de la fenêtre ;
- "Mse_StartPos" , qui est la variable de définition de la position initiale du curseur ;
- "b_Cursor" et "b_LoadedIcon" , qui sont des variables booléennes supposées fausses au départ.
4. Procédé selon la revendication 1 ou 3 , caractérisé en ce que les filtres sont en nombre de 2.
- un premier WH_GETMESSAGE permettant de recevoir les messages postés par les interruptions hardwate, tels que : WM_NCLBUTTONDOWN
WM_MOUSEMOVE
WM_KEYDOWN
WM_SYSKEYDOWN
- et un deuxième filtre WH_CALLWNDPROC permettant de filtrer et de recevoir les messages envoyés à la méthode, tel que : WM_SYSCOMMAND
WM_ACTIVATEAPP
WM_NCACTIVATE
WM ACTIVATE
5. Procédé selon la revendication 4, caractérisé en ce que l'interception d'un message déclenche le traitement d'un programme spécifique à chaque message et fait intervenir les paramètres conservés et des. fonctions principales de traitement telles que :
- ABMSInit pour initialiser un traitement ;
- ABMSMove pour effectuer le déplacement de la fenêtre ;
- et ABMSEnd pour terminer un traitement ; et qui elles-mêmes font appel à des fonctions utilitaires.
6. Procédé selon la revendication 5, caractérisé en ce que la fonction ABMSInit est mise en oeuvre uniquement pour le traitement des messages "WM_BUTTONDOWN" et "SC_SIZE" qui est un message dépendant de "WM_SYSCOMMAND" .
7. Procédé selon la revendication 5, caractérisé en ce que la fonction ABMSEnd est mise en oeuvre uniquement pour le traitement des messages "WM_LBUTTONUP" et "VK_ESCAPE" , "VK_RETURN" qui dépendent de "WM_SYSKEYDOWN" .
8. Procédé selon la revendication 5, caractérisé en ce que la fonction ABMSMove est mise en oeuvre uniquement pour le traitement des messages "WM_MOUSEMOVE, VK_LEFT, VK_UP, VK_RIGHT et VK_DOWN qui sont des messages dépendant de WM_SYSKEYDOWN.
9. Procédé selon la revendication 6, caractérisé en ce que la fonction ABMSInit consiste à approprier les messages souris par l'instruction SETCAPTURE, puis à regarder si la fenêtre est une fenêtre fille d'une fenêtre mère, c'est-à-dire inscrite dans la fenêtre mère pour limiter les mouvements de la fenêtre fille, puis à initialiser les coordonnées initiales de la fenêtre et la position du curseur pour devenir les coordonnées courantes et à initialiser les paramètres caractéristiques de la fenêtre (w-CXframe, w_CXMindWidth, w_CYMinHeigth).
10. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il compre.-u les étapes suivantes, de la part de l'application spécifique : - passage en mode actif des filtres ; mémorisation de 1 'identifieur de la fenêtre h_Wnd, destinataire du message ; - mémorisation du type d'action résultant de la zone de clic, cette mémorisation se faisant par la fonction HitTest (501) et la fonction ABMSInit (502, 503) ; - appropriation des messages souris ultérieurs pour le compte de la fenêtre en cause ;
- premier dessin du cadre fantôme autour de la fenêtre par la procédure InvertBlock (5030) ; - neutralisation du message par remplacement et substitution d'un message "WM_ENTERIDLE" qui n'est pas traité et ne provoque aucune action de la part de Windows.
11. Procédé selon la revendicaticn 10, caractérisé en ce qu'il comprend les étapes suivantes :
- calcul des coordonnées finales de la fenêtre par la procédure ABMSComputNewPos , effacement du fantôme par InvertBlock ;
- dessin de la fenêtre en position finale par la fonction ABMSMove (511) ;
- remise à 0 des paramètres de mémorisation par la fonction ABMoEnd (521).
12. Procédé selon la revendication 11, caractérisé en ce qu'il comprend en outre les étapes suivantes : abandon de la propriété des messages souris par l'instruction Release Capture ;
- passage du filtre (4) en mode passant
PCT/FR1991/000612 1990-08-02 1991-07-24 Procede de retaillage ou de deplacement de fenetres WO1992002921A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR90/09884 1990-08-02
FR9009884A FR2665552B1 (fr) 1990-08-02 1990-08-02 Procede de retaillage ou de deplacement de fenetres.

Publications (1)

Publication Number Publication Date
WO1992002921A1 true WO1992002921A1 (fr) 1992-02-20

Family

ID=9399353

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1991/000612 WO1992002921A1 (fr) 1990-08-02 1991-07-24 Procede de retaillage ou de deplacement de fenetres

Country Status (5)

Country Link
EP (1) EP0470881A1 (fr)
JP (2) JP2925734B2 (fr)
CA (1) CA2066180C (fr)
FR (1) FR2665552B1 (fr)
WO (1) WO1992002921A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3592549B2 (ja) * 1998-09-24 2004-11-24 株式会社東芝 情報処理システム及びシュミレーションシステム

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
COMPUTER vol. 19, no. 9, Septembre 1986, LONG BEACH, US pages 57 - 67; B.A. MYERS: 'A complete and efficient implementation of covered windows' voir page 65, colonne du milieu, ligne 14 ligne 32 voir page 66, colonne de droite, ligne 52 - page 67, colonne de gauche, ligne 20 SA 50215 030 *
Computer, volume 19, no. 9, septembre 1986, IEEE (Long Beach, US), B.A. Myers: "A complete and efficient implementation of covered windows", pages 57-67, voir page 65, colonne du milieu, lignes 14-32; page 66, colonne de droite, ligne 52 - page 67, colonne de gauche, ligne 20 *
PROCEEDING OF THE 1ST INTERNATIONAL CONFERENCE ON COMPUTER WORKSTATIONS Novembre 1985, SAN JOSE, US pages 12 - 21; M.J. GOODFELLOW: 'WHIM, the window handler and input manager' voir sections 1, 3.1, 3.2; note en bas de page 15 *
Proceedings of the 1st International Conference on Computer Workstations, 11-14 novembre 1985, IEEE (San Jose, California, US), M.J. Goodfellow: "WHIM, the window handler and input manager", pages 12-21, see sections 1, 3.1, 3.2; note en bas de page 15 *

Also Published As

Publication number Publication date
FR2665552B1 (fr) 1992-10-16
JP2925734B2 (ja) 1999-07-28
EP0470881A1 (fr) 1992-02-12
CA2066180C (fr) 1998-11-03
JPH04505681A (ja) 1992-10-01
JPH1195889A (ja) 1999-04-09
FR2665552A1 (fr) 1992-02-07
CA2066180A1 (fr) 1992-02-03

Similar Documents

Publication Publication Date Title
US5611040A (en) Method and system for activating double click applications with a single click
US5455904A (en) Method of sizing or moving windows
US7788474B2 (en) Operating system shut down
US7137072B2 (en) Method and system for managing documents modified while being viewed in a browser window
EP0622730B1 (fr) Encapsulation en objets d'extraits de documents
JP3368188B2 (ja) マルチタスク・データ処理システム及び方法
US5617526A (en) Operating system provided notification area for displaying visual notifications from application programs
US5546527A (en) Overriding action defaults in direct manipulation of objects on a user interface by hovering a source object
US5448695A (en) Method and apparatus for dynamic visual feedback messaging in a graphical user interface of a data processing system
JP2544116B2 (ja) マルチ処理ウインドウ表示方法
US7533277B2 (en) Operating system shut down
US5437006A (en) Spreadsheet command/function capability from a dynamic-link library
US20100053221A1 (en) Information processing apparatus and operation method thereof
EP3215900A1 (fr) Automatisation de processus robotique
US5812804A (en) Display apparatus for tossing windows
CN113407086B (zh) 对象拖拽方法、设备和存储介质
WO2017001560A1 (fr) Automatisation de processus robotique
EP1006440B1 (fr) Interaction entre widgets d'affichage dans des systèmes intégrés en utilisant des sous-contextes graphiques
CN109145273B (zh) 一种批注跟随显示方法、装置、设备和存储介质
WO1992002921A1 (fr) Procede de retaillage ou de deplacement de fenetres
JP2000200179A (ja) 組込みシステム内におけるバッファレス子グラフィックス・コンテキストを使用したアプレット及びアプリケ―ションの表示
EP2634679A1 (fr) Entrée de rotation à deux facteurs sur un dispositif à écran tactile
JPH06511337A (ja) インタラクティブオペレーションのためのポーズユーティリティーを有するコンピュータグラフィックスシステム
CN114527895A (zh) 一种界面操作方法、装置、设备、终端和存储介质
CN117395493A (zh) 拍摄控制方法、装置和电子设备

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP US

WWE Wipo information: entry into national phase

Ref document number: 2066180

Country of ref document: CA