[0001] L'invention concerne un procédé de retaillage ou de déplacement de fenêtres.
[0002] 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.
[0003] La présente invention a pour but de pallier cet inconvénient.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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".
[0010] 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".
[0011] 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".
[0012] 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).
[0013] 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.
[0014] 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 à O des paramètres de mémorisation par la fonction ABMSEnd.
[0015] 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.
[0016] 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 ;
- les figures 5 à 12 représentent le détail des différentes étapes représentées dans
l'organigramme de la figure 4 ;
- la figure 13 représente l'art antérieur à l'invention.
[0017] 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.
[0018] Dans l'art antérieur de la figure 13, 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'inconvenients. 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 13 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éé. 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 prevoit 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 reconnaitre 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 que 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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,
fig. 5) 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, fig. 5) 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) aux figures 2 et
5, et s'effectuant par la fonction "SETWINDOWSHOOK". La cloture de l'application ABMS
retire les filtres, ce retrait étant représenté par la référence (41) aux figures
2 et 5 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.
[0023] 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.
[0024] 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 ;
- "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 au 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_CXMindWidth", 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.
[0025] 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églacer 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 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 la figure 11, et par le programme ABMSInit, portant
les références (502, 503) sur la figure 7 ;
- 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 à la figure 8 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.
[0026] Lorsque le programme ABMS est lancé, une première fonction, représentée à la figure
5 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_NCL BUTTONDOWN, 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.
[0027] 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 la figure 5 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), figure 5, représenté en détail à la figure 11 par la
référence (501), et lance le sous-programme ABMSInit (502, 503), figure 5, représenté
en détail par les références (502, 503) à la figure 8. 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".
[0028] 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 la
figure 5 à 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 à la figure 5. Cette séquence
lance le sous-programme ABMSEnd qui à la fin rend la main au noyau (1) de Windows
pour l'envoi du message "WM_ENTERIDLE".
[0029] 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), figure 5 ; 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), figure 9, sinon
la fonction ABMSDirection (512), figure 10, est lancée pour initialiser les variables
de direction avec comme paramètres le résultat de la fonction ABMSTestDirect (513),
figure 12. 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 ABMSLoadIcon (5100). Ensuite, la séquence rend la main à Windows en envoyant
le message "WM_ENTERIDLE".
[0030] 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.
[0031] 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 la figure 10 ;
- 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.
[0032] 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" ;
[0033] 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.
[0034] 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), figure 9, 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), figure 10, sert à déterminer la forme du curseur
et à initialiser les variables de direction en fonction des messages reçus. Cette
fonction ABMSDirection (512), figure 10, 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), figure 11, 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.
[0035] Ainsi, comme on peut le voir à la figure 11 lorsque l'on reçoit un message HT_TopRight,
qui indique que le coin haut droit a été cliqué par la souris, la fonction ABMSHitTest
met à 1 les variables W_Top 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), figure 11, 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), figure 11, 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 ABMSLoadIcon (5100), figure 12, 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 la figure 12, 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), figure 9, 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 figures 9 et 11, 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 !a référence
(5112).
- la fonction ABMSEnd (521), figure 8, 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.
[0036] 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"
[0037] De même, le filtre GetMsgHook filtre les messages "WM_NCLBUTTONDOWN, WM_MOUSEMOVE,
WM_LBUTTONUP, WM_KEYDOWN, 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 ), figure
5, 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),
figure 9, sinon la fonction ABMSDirection (512), figure 10, est lancée pour initialiser
les variables de direction avec comme paramètres le résultat de la fonction ABMSTestDirect
(513), figure 12. 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 ABMSLoadIcor. ( 5100 ). Ensuite, la séquence rend la main à Windows en
envoyant le message "WM_ENTERIDLE".
[0038] 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".
[0039] 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 ABMSLoadIcon (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 moment-là, 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".
[0040] 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 ci-dessus et du listing figurant
dans les figures.
[0041] Toute modification à la portée de l'homme de métier fait également partie de l'esprit
de l'invention.
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 a 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_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
specifique 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_SYSDEYDOWN
- et un deuxième filtre WH_CALLWNDPROC permettant de filtrer et de recevoir les messages
envoyés à la methode, 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 gour 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éde selon la revendication 1 ou 2, caractérisé en ce qu'il comprend les étapes
suivantes, de la part de l'application spécifique :
- 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 (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 revendication 10, caractérisé en ce qu'il comprend les étages 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 ABMSEnd (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.