Partager via


Caractéristiques des fenêtres

Cette vue d’ensemble présente les fonctionnalités des fenêtres telles que les types de fenêtres, les états, la taille et la position.

Types de fenêtres

Cette section contient les rubriques suivantes qui décrivent les types de fenêtres.

Fenêtres superposées

Une fenêtre superposée est une fenêtre de niveau supérieur (fenêtre non enfant) qui a une barre de titre, une bordure et une zone cliente ; elle est destinée à servir de fenêtre main d’une application. Il peut également avoir un menu de fenêtre, des boutons de réduction et d’agrandissement, et des barres de défilement. Une fenêtre superposée utilisée comme fenêtre de main comprend généralement tous ces composants.

En spécifiant le style WS_OVERLAPPED ou WS_OVERLAPPEDWINDOW dans la fonction CreateWindowEx , une application crée une fenêtre qui se chevauche. Si vous utilisez le style WS_OVERLAPPED , la fenêtre a une barre de titre et une bordure. Si vous utilisez le style WS_OVERLAPPEDWINDOW , la fenêtre dispose d’une barre de titre, d’une bordure de dimensionnement, d’un menu de fenêtre et de boutons réduire et agrandir.

Fenêtres contextuelles

Une fenêtre contextuelle est un type spécial de fenêtre superposée utilisée pour les boîtes de dialogue, les boîtes de message et d’autres fenêtres temporaires qui s’affichent en dehors de la fenêtre main d’une application. Les barres de titre sont facultatives pour les fenêtres contextuelles ; sinon, les fenêtres contextuelles sont identiques aux fenêtres superposées du style WS_OVERLAPPED .

Vous créez une fenêtre contextuelle en spécifiant le style WS_POPUP dans CreateWindowEx. Pour inclure une barre de titre, spécifiez le style WS_CAPTION . Utilisez le style WS_POPUPWINDOW pour créer une fenêtre contextuelle avec une bordure et un menu de fenêtre. Le style WS_CAPTION doit être combiné avec le style WS_POPUPWINDOW pour rendre le menu de la fenêtre visible.

Windows enfant

Une fenêtre enfant a le style WS_CHILD et est limitée à la zone cliente de sa fenêtre parente. Une application utilise généralement des fenêtres enfants pour diviser la zone cliente d’une fenêtre parente en zones fonctionnelles. Vous créez une fenêtre enfant en spécifiant le style WS_CHILD dans la fonction CreateWindowEx .

Une fenêtre enfant doit avoir une fenêtre parente. La fenêtre parente peut être une fenêtre superposée, une fenêtre contextuelle ou même une autre fenêtre enfant. Vous spécifiez la fenêtre parente lorsque vous appelez CreateWindowEx. Si vous spécifiez le style WS_CHILD dans CreateWindowEx , mais que vous ne spécifiez pas de fenêtre parente, le système ne crée pas la fenêtre.

Une fenêtre enfant a une zone cliente, mais aucune autre fonctionnalité, sauf si elles sont explicitement demandées. Une application peut demander une barre de titre, un menu de fenêtre, des boutons réduire et agrandir, une bordure et des barres de défilement pour une fenêtre enfant, mais une fenêtre enfant ne peut pas avoir de menu. Si l’application spécifie un handle de menu, lors de l’inscription de la classe de fenêtre enfant ou de la création de la fenêtre enfant, le handle de menu est ignoré. Si aucun style de bordure n’est spécifié, le système crée une fenêtre sans bordure. Une application peut utiliser des fenêtres enfants sans bordure pour diviser la zone cliente d’une fenêtre parente tout en gardant les divisions invisibles pour l’utilisateur.

Cette section décrit les aspects suivants des fenêtres enfants :

Positionnement

Le système positionne toujours une fenêtre enfant par rapport au coin supérieur gauche de la zone cliente de sa fenêtre parente. Aucune partie d’une fenêtre enfant n’apparaît jamais en dehors des bordures de sa fenêtre parente. Si une application crée une fenêtre enfant qui est plus grande que la fenêtre parente ou positionne une fenêtre enfant de sorte qu’une partie ou la totalité de la fenêtre enfant s’étend au-delà des bordures du parent, le système clipse la fenêtre enfant ; autrement dit, la partie située en dehors de la zone cliente de la fenêtre parente n’est pas affichée. Les actions qui affectent la fenêtre parente peuvent également affecter la fenêtre enfant, comme suit.

Fenêtre parente Fenêtre enfant
Détruit Détruit avant la destruction de la fenêtre parente.
Hidden Masqué avant que la fenêtre parente ne soit masquée. Une fenêtre enfant n’est visible que lorsque la fenêtre parente est visible.
Déplacé Déplacé avec la zone cliente de la fenêtre parente. La fenêtre enfant est chargée de peindre sa zone cliente après le déplacement.
Montré Affiché après l’affichage de la fenêtre parente.

 

Découpage

Le système ne coupe pas automatiquement une fenêtre enfant de la zone cliente de la fenêtre parente. Cela signifie que la fenêtre parente dessine sur la fenêtre enfant si elle effectue un dessin au même emplacement que la fenêtre enfant. Toutefois, le système coupe la fenêtre enfant de la zone cliente de la fenêtre parente si la fenêtre parente a le style WS_CLIPCHILDREN . Si la fenêtre enfant est coupée, la fenêtre parente ne peut pas dessiner dessus.

Une fenêtre enfant peut chevaucher d’autres fenêtres enfants dans la même zone cliente. Une fenêtre enfant qui partage la même fenêtre parente qu’une ou plusieurs autres fenêtres enfants est appelée fenêtre frère. Les fenêtres frères peuvent dessiner dans la zone cliente de l’autre, sauf si l’une des fenêtres enfants a le style WS_CLIPSIBLINGS . Si une fenêtre enfant a ce style, toute partie de sa fenêtre sœur qui se trouve dans la fenêtre enfant est clippée.

Si une fenêtre a le style WS_CLIPCHILDREN ou WS_CLIPSIBLINGS , une légère perte de performances se produit. Chaque fenêtre occupe des ressources système. Par conséquent, une application ne doit pas utiliser les fenêtres enfants sans discrimination. Pour de meilleures performances, une application qui doit diviser logiquement sa fenêtre main doit le faire dans la procédure de fenêtre de la fenêtre main plutôt qu’en utilisant des fenêtres enfants.

Relation à la fenêtre parente

Une application peut modifier la fenêtre parente d’une fenêtre enfant existante en appelant la fonction SetParent . Dans ce cas, le système supprime la fenêtre enfant de la zone cliente de l’ancienne fenêtre parente et la déplace vers la zone cliente de la nouvelle fenêtre parente. Si SetParent spécifie un handle NULL , la fenêtre de bureau devient la nouvelle fenêtre parente. Dans ce cas, la fenêtre enfant est dessinée sur le bureau, en dehors des bordures de toute autre fenêtre. La fonction GetParent récupère un handle dans la fenêtre parente d’une fenêtre enfant.

La fenêtre parente abandonne une partie de sa zone cliente à une fenêtre enfant, et la fenêtre enfant reçoit toutes les entrées de cette zone. La classe window n’a pas besoin d’être la même pour chacune des fenêtres enfants de la fenêtre parente. Cela signifie qu’une application peut remplir une fenêtre parente avec des fenêtres enfants qui semblent différentes et effectuent différentes tâches. Par exemple, une boîte de dialogue peut contenir de nombreux types de contrôles, chacun d’entre eux une fenêtre enfant qui accepte différents types de données de l’utilisateur.

Une fenêtre enfant n’a qu’une seule fenêtre parente, mais un parent peut avoir n’importe quel nombre de fenêtres enfants. Chaque fenêtre enfant, à son tour, peut avoir des fenêtres enfants. Dans cette chaîne de fenêtres, chaque fenêtre enfant est appelée fenêtre descendante de la fenêtre parente d’origine. Une application utilise la fonction IsChild pour déterminer si une fenêtre donnée est une fenêtre enfant ou une fenêtre descendante d’une fenêtre parente donnée.

La fonction EnumChildWindows énumère les fenêtres enfants d’une fenêtre parente. Ensuite, EnumChildWindows transmet le handle à chaque fenêtre enfant à une fonction de rappel définie par l’application. Les fenêtres descendantes de la fenêtre parente donnée sont également énumérées.

Messages

Le système transmet les messages d’entrée d’une fenêtre enfant directement à la fenêtre enfant ; les messages ne sont pas passés par la fenêtre parente. La seule exception est si la fenêtre enfant a été désactivée par la fonction EnableWindow . Dans ce cas, le système transmet les messages d’entrée qui auraient été envoyés à la fenêtre enfant à la fenêtre parente à la place. Cela permet à la fenêtre parente d’examiner les messages d’entrée et d’activer la fenêtre enfant, si nécessaire.

Une fenêtre enfant peut avoir un identificateur entier unique. Les identificateurs de fenêtre enfants sont importants lors de l’utilisation de fenêtres de contrôle. Une application dirige l’activité d’un contrôle en lui envoyant des messages. L’application utilise l’identificateur de fenêtre enfant du contrôle pour diriger les messages vers le contrôle. En outre, un contrôle envoie des messages de notification à sa fenêtre parente. Un message de notification inclut l’identificateur de fenêtre enfant du contrôle, que le parent utilise pour identifier le contrôle qui a envoyé le message. Une application spécifie l’identificateur de fenêtre enfant pour d’autres types de fenêtres enfants en définissant le paramètre hMenu de la fonction CreateWindowEx sur une valeur plutôt qu’un handle de menu.

Windows en couches

L’utilisation d’une fenêtre en couches peut améliorer considérablement les performances et les effets visuels d’une fenêtre qui a une forme complexe, anime sa forme ou souhaite utiliser des effets de fusion alpha. Le système compose et repeint automatiquement les fenêtres en couche et les fenêtres des applications sous-jacentes. Par conséquent, les fenêtres en couches sont rendues en douceur, sans le scintillement typique des régions de fenêtres complexes. En outre, les fenêtres en couches peuvent être partiellement translucides, c’est-à-dire alpha-blended.

Pour créer une fenêtre en couches, spécifiez le style de fenêtre étendu WS_EX_LAYERED lors de l’appel de la fonction CreateWindowEx , ou appelez la fonction SetWindowLong pour définir WS_EX_LAYERED après la création de la fenêtre. Après l’appel CreateWindowEx , la fenêtre en couches n’est pas visible tant que la fonction SetLayeredWindowAttributes ou UpdateLayeredWindow n’a pas été appelée pour cette fenêtre.

Notes

À compter de Windows 8, WS_EX_LAYERED peut être utilisé avec des fenêtres enfants et des fenêtres de niveau supérieur. Les versions précédentes de Windows prennent en charge WS_EX_LAYERED uniquement pour les fenêtres de niveau supérieur.

 

Pour définir le niveau d’opacité ou la clé de couleur de transparence pour une fenêtre en couches donnée, appelez SetLayeredWindowAttributes. Après l’appel, le système peut toujours demander à la fenêtre de peindre lorsque la fenêtre est affichée ou redimensionnée. Toutefois, étant donné que le système stocke l’image d’une fenêtre en couches, le système ne demande pas à la fenêtre de peindre si des parties de celle-ci sont révélées à la suite de mouvements de fenêtre relatifs sur le bureau. Les applications héritées n’ont pas besoin de restructurer leur code de peinture si elles veulent ajouter des effets de transparence ou de transparence pour une fenêtre, car le système redirige la peinture des fenêtres appelée SetLayeredWindowAttributes dans la mémoire hors écran et la recompose pour obtenir l’effet souhaité.

Pour une animation plus rapide et plus efficace ou si l’alpha par pixel est nécessaire, appelez UpdateLayeredWindow. UpdateLayeredWindow doit être utilisé principalement lorsque l’application doit fournir directement la forme et le contenu d’une fenêtre en couches, sans utiliser le mécanisme de redirection fourni par le système via SetLayeredWindowAttributes. En outre, l’utilisation de UpdateLayeredWindow utilise directement la mémoire plus efficacement, car le système n’a pas besoin de la mémoire supplémentaire nécessaire pour stocker l’image de la fenêtre redirigée. Pour une efficacité maximale dans l’animation de fenêtres, appelez UpdateLayeredWindow pour modifier la position et la taille d’une fenêtre en couches. Notez qu’une fois que SetLayeredWindowAttributes a été appelé, les appels UpdateLayeredWindow suivants échouent jusqu’à ce que le bit de style de superposition soit effacé et défini à nouveau.

Le test d’accès d’une fenêtre en couches est basé sur la forme et la transparence de la fenêtre. Cela signifie que les zones de la fenêtre qui sont en couleur ou dont la valeur alpha est égale à zéro laissent passer les messages de la souris. Toutefois, si la fenêtre en couches a le style de fenêtre étendu WS_EX_TRANSPARENT, la forme de la fenêtre en couches est ignorée et les événements de souris sont passés à d’autres fenêtres sous la fenêtre en couches.

Message-Only Windows

Une fenêtre de message uniquement vous permet d’envoyer et de recevoir des messages. Il n’est pas visible, n’a pas d’ordre z, ne peut pas être énuméré et ne reçoit pas de messages diffusés. La fenêtre distribue simplement les messages.

Pour créer une fenêtre de message uniquement, spécifiez la constante HWND_MESSAGE ou un handle dans une fenêtre de message uniquement existante dans le paramètre hWndParent de la fonction CreateWindowEx . Vous pouvez également remplacer une fenêtre existante par une fenêtre de message uniquement en spécifiant HWND_MESSAGE dans le paramètre hWndNewParent de la fonction SetParent .

Pour rechercher des fenêtres de message uniquement, spécifiez HWND_MESSAGE dans le paramètre hwndParent de la fonction FindWindowEx . En outre, FindWindowEx recherche les fenêtres de message uniquement ainsi que les fenêtres de niveau supérieur si les paramètres hwndParent et hwndChildAfter sont NULL.

Relations de fenêtre

Une fenêtre peut être liée à l’utilisateur ou à une autre fenêtre de plusieurs façons. Une fenêtre peut être une fenêtre détenue, une fenêtre de premier plan ou une fenêtre d’arrière-plan. Une fenêtre a également un ordre z par rapport aux autres fenêtres. Pour plus d'informations, voir les rubriques suivantes :

Fenêtres de premier plan et d’arrière-plan

Chaque processus peut avoir plusieurs threads d’exécution, et chaque thread peut créer des fenêtres. Le thread qui a créé la fenêtre avec laquelle l’utilisateur travaille actuellement est appelé thread de premier plan, et la fenêtre est appelée fenêtre de premier plan. Tous les autres threads sont des threads d’arrière-plan, et les fenêtres créées par les threads d’arrière-plan sont appelées fenêtres d’arrière-plan.

Chaque thread a un niveau de priorité qui détermine la durée de processeur que le thread reçoit. Bien qu’une application puisse définir le niveau de priorité de ses threads, le thread de premier plan a normalement un niveau de priorité légèrement supérieur à celui des threads d’arrière-plan. Étant donné qu’il a une priorité plus élevée, le thread de premier plan reçoit plus de temps processeur que les threads d’arrière-plan. Le thread de premier plan a une priorité de base normale de 9 ; un thread d’arrière-plan a une priorité de base normale de 7.

L’utilisateur définit la fenêtre de premier plan en cliquant sur une fenêtre ou à l’aide de la combinaison alt+tab ou ALT+Échap. Pour récupérer un handle dans la fenêtre de premier plan, utilisez la fonction GetForegroundWindow . Pour case activée si votre fenêtre d’application est la fenêtre de premier plan, comparez le handle retourné par GetForegroundWindow à celui de votre fenêtre d’application.

Une application définit la fenêtre de premier plan à l’aide de la fonction SetForegroundWindow .

Le système restreint les processus qui peuvent définir la fenêtre de premier plan. Un processus peut définir la fenêtre de premier plan uniquement si :

  • Toutes les conditions suivantes sont remplies :
    • Le processus appelant SetForegroundWindow appartient à une application de bureau, et non à une application UWP ou à une application du Windows Store conçue pour Windows 8 ou 8.1.
    • Le processus de premier plan n’a pas désactivé les appels à SetForegroundWindow par un appel précédent à la fonction LockSetForegroundWindow .
    • Le délai d’expiration du verrou de premier plan a expiré (voir SPI_GETFOREGROUNDLOCKTIMEOUT dans SystemParametersInfo).
    • Aucun menu n’est actif.
  • En outre, au moins l’une des conditions suivantes est vraie :
    • Le processus appelant est le processus de premier plan.
    • Le processus d’appel a été démarré par le processus de premier plan.
    • Il n’existe actuellement aucune fenêtre de premier plan, et donc aucun processus de premier plan.
    • Le processus appelant a reçu le dernier événement d’entrée.
    • Le processus de premier plan ou le processus appelant est en cours de débogage.

Il est possible qu’un processus se voit refuser le droit de définir la fenêtre de premier plan même s’il remplit ces conditions.

Un processus qui peut définir la fenêtre de premier plan peut permettre à un autre processus de définir la fenêtre de premier plan en appelant la fonction AllowSetForegroundWindow ou en appelant la fonction BroadcastSystemMessage avec l’indicateur BSF_ALLOWSFW . Le processus de premier plan peut désactiver les appels à SetForegroundWindow en appelant la fonction LockSetForegroundWindow .

Windows possédé

Une fenêtre contextuelle ou superposée peut appartenir à une autre fenêtre superposée ou contextuelle. Le fait d’être possédé place plusieurs contraintes sur une fenêtre.

  • Une fenêtre appartenant est toujours au-dessus de son propriétaire dans l’ordre z.
  • Le système détruit automatiquement une fenêtre propriétaire lorsque son propriétaire est détruit.
  • Une fenêtre appartenant est masquée lorsque son propriétaire est réduit.

Seule une fenêtre contextuelle ou superposée peut être une fenêtre propriétaire ; une fenêtre enfant ne peut pas être une fenêtre propriétaire. Une application crée une fenêtre appartenant en spécifiant le handle de fenêtre du propriétaire comme paramètre hwndParent de CreateWindowEx lorsqu’elle crée une fenêtre avec le style WS_OVERLAPPED ou WS_POPUP . Le paramètre hwndParent doit identifier une fenêtre superposée ou contextuelle. Si hwndParent identifie une fenêtre enfant, le système attribue la propriété à la fenêtre parente de niveau supérieur de la fenêtre enfant. Après avoir créé une fenêtre détenue, une application ne peut pas transférer la propriété de la fenêtre vers une autre fenêtre.

Les boîtes de dialogue et les boîtes de message appartiennent aux fenêtres par défaut. Une application spécifie la fenêtre propriétaire lors de l’appel d’une fonction qui crée une boîte de dialogue ou une boîte de message.

Une application peut utiliser la fonction GetWindow avec l’indicateur GW_OWNER pour récupérer un handle au propriétaire d’une fenêtre.

Ordre Z

L’ordre z d’une fenêtre indique la position de la fenêtre dans une pile de fenêtres qui se chevauchent. Cette pile de fenêtres est orientée le long d’un axe imaginaire, l’axe z, s’étendant vers l’extérieur de l’écran. La fenêtre située en haut de l’ordre z chevauche toutes les autres fenêtres. La fenêtre située en bas de l’ordre z est superposée par toutes les autres fenêtres.

Le système gère l’ordre z dans une liste unique. Il ajoute des fenêtres à l’ordre z selon qu’il s’agit de fenêtres les plus supérieures, de fenêtres de niveau supérieur ou de fenêtres enfants. Une fenêtre la plus supérieure chevauche toutes les autres fenêtres non supérieures, qu’il s’agisse de la fenêtre active ou de la fenêtre de premier plan. Une fenêtre supérieure a le style WS_EX_TOPMOST . Toutes les fenêtres les plus hauts s’affichent dans l’ordre Z avant toutes les fenêtres non les plus en haut. Une fenêtre enfant est regroupée avec son parent dans l’ordre z.

Lorsqu’une application crée une fenêtre, le système la place en haut de l’ordre z pour les fenêtres du même type. Vous pouvez utiliser la fonction BringWindowToTop pour placer une fenêtre en haut de l’ordre z pour les fenêtres du même type. Vous pouvez réorganiser l’ordre z à l’aide des fonctions SetWindowPos et DeferWindowPos .

L’utilisateur modifie l’ordre z en activant une autre fenêtre. Le système positionne la fenêtre active en haut de l’ordre z pour les fenêtres du même type. Lorsqu’une fenêtre arrive en haut de l’ordre z, il en va de même pour ses fenêtres enfants. Vous pouvez utiliser la fonction GetTopWindow pour rechercher toutes les fenêtres enfants d’une fenêtre parente et retourner un handle à la fenêtre enfant qui est le plus élevé dans l’ordre z. La fonction GetNextWindow récupère un handle dans la fenêtre suivante ou précédente dans l’ordre z.

Fenêtre Afficher l’état

À un moment donné, une fenêtre peut être active ou inactive; masqué ou visible ; et réduit, agrandi ou restauré. Ces qualités sont collectivement appelées état d’affichage de fenêtre. Les rubriques suivantes traitent de l’état d’affichage de la fenêtre :

Fenêtre active

Une fenêtre active est la fenêtre de niveau supérieur de l’application avec laquelle l’utilisateur travaille actuellement. Pour permettre à l’utilisateur d’identifier facilement la fenêtre active, le système la place en haut de l’ordre z et modifie la couleur de sa barre de titre et de sa bordure en couleurs de fenêtre actives définies par le système. Seule une fenêtre de niveau supérieur peut être une fenêtre active. Lorsque l’utilisateur travaille avec une fenêtre enfant, le système active la fenêtre parente de niveau supérieur associée à la fenêtre enfant.

Une seule fenêtre de niveau supérieur dans le système est active à la fois. L’utilisateur active une fenêtre de niveau supérieur en cliquant dessus (ou l’une de ses fenêtres enfants), ou en utilisant la combinaison ALT+ÉCHAP ou ALT+TAB. Une application active une fenêtre de niveau supérieur en appelant la fonction SetActiveWindow . D’autres fonctions peuvent amener le système à activer une autre fenêtre de niveau supérieur, notamment SetWindowPos, DeferWindowPos, SetWindowPlacement et DestroyWindow. Bien qu’une application puisse activer une autre fenêtre de niveau supérieur à tout moment, pour éviter de confondre l’utilisateur, elle ne doit le faire qu’en réponse à une action de l’utilisateur. Une application utilise la fonction GetActiveWindow pour récupérer un handle dans la fenêtre active.

Lorsque l’activation passe d’une fenêtre de niveau supérieur d’une application à la fenêtre de niveau supérieur d’une autre, le système envoie un message WM_ACTIVATEAPP aux deux applications, les informant de la modification. Lorsque l’activation passe à une autre fenêtre de niveau supérieur dans la même application, le système envoie aux deux fenêtres un message WM_ACTIVATE .

Windows désactivé

Une fenêtre peut être désactivée. Une fenêtre désactivée ne reçoit aucune entrée de clavier ou de souris de la part de l’utilisateur, mais elle peut recevoir des messages d’autres fenêtres, d’autres applications et du système. Une application désactive généralement une fenêtre pour empêcher l’utilisateur d’utiliser la fenêtre. Par exemple, une application peut désactiver un bouton push dans une boîte de dialogue pour empêcher l’utilisateur de le choisir. Une application peut activer une fenêtre désactivée à tout moment ; l’activation d’une fenêtre restaure l’entrée normale.

Par défaut, une fenêtre est activée lors de sa création. Une application peut toutefois spécifier le style WS_DISABLED pour désactiver une nouvelle fenêtre. Une application active ou désactive une fenêtre existante à l’aide de la fonction EnableWindow . Le système envoie un message WM_ENABLE à une fenêtre lorsque son état activé est sur le point de changer. Une application peut déterminer si une fenêtre est activée à l’aide de la fonction IsWindowEnabled .

Lorsqu’une fenêtre enfant est désactivée, le système transmet les messages d’entrée de la souris de l’enfant à la fenêtre parente. Le parent utilise les messages pour déterminer s’il faut activer la fenêtre enfant. Pour plus d’informations, consultez Entrée de souris.

Une seule fenêtre à la fois peut recevoir l’entrée du clavier ; cette fenêtre est dite avec le focus clavier. Si une application utilise la fonction EnableWindow pour désactiver une fenêtre de focus clavier, la fenêtre perd le focus du clavier en plus d’être désactivée. EnableWindow définit ensuite le focus du clavier sur NULL, ce qui signifie qu’aucune fenêtre n’a le focus. Si une fenêtre enfant ou une autre fenêtre descendante a le focus clavier, la fenêtre descendante perd le focus lorsque la fenêtre parente est désactivée. Pour plus d’informations, consultez Entrée clavier.

Visibilité de la fenêtre

Une fenêtre peut être soit visible, soit masquée. Le système affiche une fenêtre visible à l’écran. Il masque une fenêtre masquée en ne la dessinant pas. Si une fenêtre est visible, l'utilisateur peut lui fournir des entrées dont elle affiche la sortie. Si une fenêtre est masquée, elle est en réalité désactivée. Une fenêtre masquée peut traiter des messages du système ou d'autres fenêtres, mais ne peut pas traiter d'entrée utilisateur ou afficher une sortie. Une application définit l’état de visibilité d’une fenêtre lors de la création de la fenêtre. Plus tard, l’application peut modifier l’état de visibilité.

Une fenêtre est visible lorsque le style WS_VISIBLE est défini pour la fenêtre. Par défaut, la fonction CreateWindowEx crée une fenêtre masquée, sauf si l’application spécifie le style WS_VISIBLE . En règle générale, une application définit le style WS_VISIBLE une fois qu’elle a créé une fenêtre pour masquer les détails du processus de création à l’utilisateur. Par exemple, une application peut garder une nouvelle fenêtre masquée pendant qu’elle personnalise l’apparence de la fenêtre. Si le style WS_VISIBLE est spécifié dans CreateWindowEx, le système envoie le message WM_SHOWWINDOW à la fenêtre après avoir créé la fenêtre, mais avant de l’afficher.

Une application peut déterminer si une fenêtre est visible à l’aide de la fonction IsWindowVisible . Une application peut afficher (rendre visible) ou masquer une fenêtre à l’aide de la fonction ShowWindow, SetWindowPos, DeferWindowPos ou SetWindowPlacement ou SetWindowLong . Ces fonctions affichent ou masquent une fenêtre en définissant ou en supprimant le style WS_VISIBLE de la fenêtre. Ils envoient également le message WM_SHOWWINDOW à la fenêtre avant de l’afficher ou de le masquer.

Lorsqu’une fenêtre propriétaire est réduite, le système masque automatiquement les fenêtres associées. De même, lorsqu’une fenêtre propriétaire est restaurée, le système affiche automatiquement les fenêtres associées. Dans les deux cas, le système envoie le message WM_SHOWWINDOW aux fenêtres détenues avant de les masquer ou de les afficher. Parfois, une application peut avoir besoin de masquer les fenêtres détenues sans avoir à réduire ou masquer le propriétaire. Dans ce cas, l’application utilise la fonction ShowOwnedPopups . Cette fonction définit ou supprime le style WS_VISIBLE pour toutes les fenêtres appartenant et envoie le message WM_SHOWWINDOW aux fenêtres détenues avant de les masquer ou de les afficher. Le masquage d’une fenêtre propriétaire n’a aucun effet sur l’état de visibilité des fenêtres détenues.

Lorsqu’une fenêtre parente est visible, les fenêtres enfants associées sont également visibles. De même, lorsque la fenêtre parente est masquée, ses fenêtres enfants sont également masquées. La réduction de la fenêtre parente n’a aucun effet sur l’état de visibilité des fenêtres enfants ; autrement dit, les fenêtres enfants sont réduites avec le parent, mais le style WS_VISIBLE n’est pas modifié.

Même si une fenêtre a le style WS_VISIBLE , l’utilisateur peut ne pas être en mesure de voir la fenêtre à l’écran ; d’autres fenêtres peuvent le chevaucher complètement ou il peut avoir été déplacé au-delà du bord de l’écran. En outre, une fenêtre enfant visible est soumise aux règles de découpage établies par sa relation parent-enfant. Si la fenêtre parente de la fenêtre n’est pas visible, elle ne sera pas non plus visible. Si la fenêtre parente se déplace au-delà du bord de l’écran, la fenêtre enfant se déplace également parce qu’une fenêtre enfant est dessinée par rapport au coin supérieur gauche du parent. Par exemple, un utilisateur peut déplacer la fenêtre parente contenant la fenêtre enfant suffisamment loin du bord de l’écran pour que l’utilisateur ne puisse pas voir la fenêtre enfant, même si la fenêtre enfant et sa fenêtre parente ont tous deux le style WS_VISIBLE .

Fenêtres réduites, agrandies et restaurées

Une fenêtre agrandie est une fenêtre qui a le style WS_MAXIMIZE . Par défaut, le système élargit une fenêtre agrandie afin qu'elle remplisse l'écran ou la zone cliente d'une fenêtre parente, s'il s'agit d'une fenêtre enfant. Bien que la taille d’une fenêtre puisse être définie sur la même taille qu’une fenêtre agrandie, une fenêtre agrandie est légèrement différente. Le système déplace automatiquement la barre de titre de la fenêtre en haut de l’écran ou en haut de la zone cliente de la fenêtre parente. En outre, le système désactive la bordure de dimensionnement de la fenêtre et la fonctionnalité de positionnement de la fenêtre de la barre de titre (afin que l’utilisateur ne puisse pas déplacer la fenêtre en faisant glisser la barre de titre).

Une fenêtre réduite est une fenêtre qui a le style WS_MINIMIZE . Par défaut, le système diminue une fenêtre réduite jusqu'à la taille de son bouton dans la barre des tâches et la déplace vers la barre des tâches. Une fenêtre restaurée est une fenêtre qui a été retournée à sa taille et à sa position précédentes, c’est-à-dire la taille qu’elle était avant d’être réduite ou agrandie.

Si une application spécifie le style WS_MAXIMIZE ou WS_MINIMIZE dans la fonction CreateWindowEx , la fenêtre est initialement agrandie ou réduite. Après avoir créé une fenêtre, une application peut utiliser la fonction CloseWindow pour réduire la fenêtre. La fonction ArrangeIconicWindows organise les icônes sur le bureau ou organise les fenêtres enfants réduites d’une fenêtre parente dans la fenêtre parente. La fonction OpenIcon restaure la taille et la position précédentes d’une fenêtre réduite.

La fonction ShowWindow peut réduire, agrandir ou restaurer une fenêtre. Il peut également définir les états de visibilité et d’activation de la fenêtre. La fonction SetWindowPlacement inclut les mêmes fonctionnalités que ShowWindow, mais elle peut remplacer les positions par défaut réduites, agrandies et restaurées de la fenêtre.

Les fonctions IsZoomed et IsIconic déterminent si une fenêtre donnée est agrandie ou réduite, respectivement. La fonction GetWindowPlacement récupère les positions réduites, agrandies et restaurées de la fenêtre, et détermine également l’état d’affichage de la fenêtre.

Lorsque le système reçoit une commande pour agrandir ou restaurer une fenêtre réduite, il envoie à la fenêtre un message WM_QUERYOPEN . Si la procédure de fenêtre retourne FALSE, le système ignore la commande agrandir ou restaurer.

Le système définit automatiquement la taille et la position d’une fenêtre agrandie sur les valeurs par défaut définies par le système pour une fenêtre agrandie. Pour remplacer ces valeurs par défaut, une application peut appeler la fonction SetWindowPlacement ou traiter le message WM_GETMINMAXINFO reçu par une fenêtre lorsque le système est sur le point d’agrandir la fenêtre. WM_GETMINMAXINFO inclut un pointeur vers une structure MINMAXINFO contenant des valeurs que le système utilise pour définir la taille et la position agrandies. Le remplacement de ces valeurs remplace les valeurs par défaut.

Taille et position de la fenêtre

La taille et la position d’une fenêtre sont exprimées sous la forme d’un rectangle englobant, donné en coordonnées par rapport à l’écran ou à la fenêtre parente. Les coordonnées d’une fenêtre de niveau supérieur sont relatives au coin supérieur gauche de l’écran ; les coordonnées d’une fenêtre enfant sont relatives au coin supérieur gauche de la fenêtre parente. Une application spécifie la taille et la position initiales d’une fenêtre lorsqu’elle crée la fenêtre, mais elle peut modifier la taille et la position de la fenêtre à tout moment. Pour plus d’informations, consultez Formes remplies.

Cette section contient les rubriques suivantes :

Taille et position par défaut

Une application peut permettre au système de calculer la taille ou la position initiale d’une fenêtre de niveau supérieur en spécifiant CW_USEDEFAULT dans CreateWindowEx. Si l’application définit les coordonnées de la fenêtre sur CW_USEDEFAULT et n’a créé aucune autre fenêtre de niveau supérieur, le système définit la position de la nouvelle fenêtre par rapport au coin supérieur gauche de l’écran ; sinon, il définit la position par rapport à la position de la fenêtre de niveau supérieur que l’application a créée récemment. Si les paramètres de largeur et de hauteur sont définis sur CW_USEDEFAULT, le système calcule la taille de la nouvelle fenêtre. Si l’application a créé d’autres fenêtres de niveau supérieur, le système base la taille de la nouvelle fenêtre sur la taille de la dernière fenêtre de niveau supérieur créée de l’application. En spécifiant CW_USEDEFAULT lors de la création d’une fenêtre enfant ou contextuelle, le système définit la taille de la fenêtre sur la taille minimale par défaut.

Taille du suivi

Le système conserve une taille de suivi minimale et maximale pour une fenêtre du style WS_THICKFRAME ; une fenêtre avec ce style a une bordure de dimensionnement. La taille minimale de suivi est la plus petite taille de fenêtre que vous pouvez produire en faisant glisser la bordure de dimensionnement de la fenêtre. De même, la taille maximale de suivi est la plus grande taille de fenêtre que vous pouvez produire en faisant glisser la bordure de dimensionnement.

Les tailles de suivi minimale et maximale d’une fenêtre sont définies sur les valeurs par défaut définies par le système lorsque le système crée la fenêtre. Une application peut découvrir les valeurs par défaut et les remplacer en traitant le message WM_GETMINMAXINFO . Pour plus d’informations, consultez Taille et position des messages.

Commandes système

Une application qui a un menu de fenêtre peut modifier la taille et la position de cette fenêtre en envoyant des commandes système. Les commandes système sont générées lorsque l’utilisateur choisit des commandes dans le menu de la fenêtre. Une application peut émuler l’action utilisateur en envoyant un message WM_SYSCOMMAND à la fenêtre. Les commandes système suivantes affectent la taille et la position d’une fenêtre.

Commande Description
SC_CLOSE Ferme la fenêtre. Cette commande envoie un message WM_CLOSE à la fenêtre. La fenêtre effectue toutes les étapes nécessaires pour propre et se détruire elle-même.
SC_MAXIMIZE Agrandit la fenêtre.
SC_MINIMIZE Réduit la fenêtre.
SC_MOVE Déplace la fenêtre.
SC_RESTORE Restaure la taille et la position précédentes d’une fenêtre réduite ou agrandie.
SC_SIZE Démarre une commande size. Pour modifier la taille de la fenêtre, utilisez la souris ou le clavier.

 

Fonctions de taille et de position

Après avoir créé une fenêtre, une application peut définir la taille ou la position de la fenêtre en appelant l’une de plusieurs fonctions différentes, notamment SetWindowPlacement, MoveWindow, SetWindowPos et DeferWindowPos. SetWindowPlacement définit la position réduite, la position agrandie, la taille et la position restaurées d’une fenêtre et l’état d’affichage. Les fonctions MoveWindow et SetWindowPos sont similaires ; les deux définissent la taille ou la position d’une seule fenêtre d’application. La fonction SetWindowPos comprend un ensemble d’indicateurs qui affectent l’état d’affichage de la fenêtre ; MoveWindow n’inclut pas ces indicateurs. Utilisez les fonctions BeginDeferWindowPos, DeferWindowPos et EndDeferWindowPos pour définir simultanément la position d’un certain nombre de fenêtres, y compris la taille, la position, la position dans l’ordre z et l’état d’affichage.

Une application peut récupérer les coordonnées du rectangle englobant d’une fenêtre à l’aide de la fonction GetWindowRect . GetWindowRect remplit une structure RECT avec les coordonnées des coins supérieur gauche et inférieur droit de la fenêtre. Les coordonnées sont relatives au coin supérieur gauche de l’écran, même pour une fenêtre enfant. La fonction ScreenToClient ou MapWindowPoints mappe les coordonnées d’écran du rectangle englobant d’une fenêtre enfant aux coordonnées relatives à la zone cliente de la fenêtre parente.

La fonction GetClientRect récupère les coordonnées de la zone cliente d’une fenêtre. GetClientRect remplit une structure RECT avec les coordonnées des coins supérieur gauche et inférieur droit de la zone cliente, mais les coordonnées sont relatives à la zone cliente elle-même. Cela signifie que les coordonnées du coin supérieur gauche d’une zone cliente sont toujours (0,0), et les coordonnées du coin inférieur droit sont la largeur et la hauteur de la zone cliente.

La fonction CascadeWindows cascade les fenêtres sur le bureau ou cascade les fenêtres enfants de la fenêtre parente spécifiée. La fonction TileWindows vignette les fenêtres du bureau ou les fenêtres enfants de la fenêtre parente spécifiée.

Taille et position des messages

Le système envoie le message WM_GETMINMAXINFO à une fenêtre dont la taille ou la position est sur le point de changer. Par exemple, le message est envoyé lorsque l’utilisateur clique sur Déplacer ou Taille dans le menu de la fenêtre ou clique sur la bordure de dimensionnement ou la barre de titre ; le message est également envoyé lorsqu’une application appelle SetWindowPos pour déplacer ou dimensionner la fenêtre. WM_GETMINMAXINFO inclut un pointeur vers une structure MINMAXINFO contenant la taille et la position agrandies par défaut pour la fenêtre, ainsi que les tailles de suivi minimales et maximales par défaut. Une application peut remplacer les valeurs par défaut en traitant WM_GETMINMAXINFO et en définissant les membres appropriés de MINMAXINFO. Une fenêtre doit avoir le style WS_THICKFRAME ou WS_CAPTION pour recevoir WM_GETMINMAXINFO. Une fenêtre avec le style WS_THICKFRAME reçoit ce message pendant le processus de création de fenêtre, ainsi que lorsqu’elle est déplacée ou dimensionnée.

Le système envoie le message WM_WINDOWPOSCHANGING à une fenêtre dont la taille, la position, la position dans l’ordre z ou l’état d’affichage est sur le point de changer. Ce message inclut un pointeur vers une structure WINDOWPOS qui spécifie la nouvelle taille, la position, la position et l’ordre z de la fenêtre. En définissant les membres de WINDOWPOS, une application peut affecter la nouvelle taille, la position et l’apparence de la fenêtre.

Après avoir modifié la taille, la position, la position ou l’état d’affichage d’une fenêtre, le système envoie le message WM_WINDOWPOSCHANGED à la fenêtre. Ce message inclut un pointeur vers WINDOWPOS qui informe la fenêtre de sa nouvelle taille, position, position dans l’ordre z et état d’affichage. La définition des membres de la structure WINDOWPOS passée avec WM_WINDOWPOSCHANGED n’a aucun effet sur la fenêtre. Une fenêtre qui doit traiter les messages WM_SIZE et WM_MOVE doit passer WM_WINDOWPOSCHANGED à la fonction DefWindowProc ; sinon, le système n’envoie pas de messages WM_SIZE et WM_MOVE à la fenêtre.

Le système envoie le message WM_NCCALCSIZE à une fenêtre lorsque la fenêtre est créée ou dimensionnée. Le système utilise le message pour calculer la taille de la zone cliente d’une fenêtre et la position de la zone cliente par rapport à l’angle supérieur gauche de la fenêtre. Une fenêtre transmet généralement ce message à la procédure de fenêtre par défaut ; Toutefois, ce message peut être utile dans les applications qui personnalisent la zone non cliente d’une fenêtre ou conservent des parties de la zone cliente lorsque la fenêtre est dimensionnée. Pour plus d’informations, consultez Peinture et dessin.

Animation de fenêtre

Vous pouvez produire des effets spéciaux lors de l’affichage ou du masquage de fenêtres à l’aide de la fonction AnimateWindow . Lorsque la fenêtre est animée de cette manière, le système la déplace, la fait glisser ou la fondue, en fonction des indicateurs que vous spécifiez dans un appel à AnimateWindow.

Par défaut, le système utilise l’animation de rouleau. Avec cet effet, la fenêtre semble s’ouvrir en roulis (montrant la fenêtre) ou rouler fermée (masquant la fenêtre). Vous pouvez utiliser le paramètre dwFlags pour spécifier si la fenêtre se déroule horizontalement, verticalement ou en diagonale.

Lorsque vous spécifiez l’indicateur AW_SLIDE , le système utilise l’animation de diapositive. Avec cet effet, la fenêtre s’affiche en mode affichage (montrant la fenêtre) ou en dehors de l’affichage (masquant la fenêtre). Vous pouvez utiliser le paramètre dwFlags pour spécifier si la fenêtre glisse horizontalement, verticalement ou en diagonale.

Lorsque vous spécifiez l’indicateur AW_BLEND , le système utilise un fondu alpha-fondu.

Vous pouvez également utiliser l’indicateur AW_CENTER pour qu’une fenêtre semble se réduire vers l’intérieur ou se développer vers l’extérieur.

Disposition et mise en miroir de fenêtres

La disposition de la fenêtre définit la façon dont le texte et les objets GDI (Windows Graphics Device Interface) sont disposés dans un contexte de fenêtre ou d’appareil (DC). Certaines langues, telles que l’anglais, le Français et l’allemand, nécessitent une disposition de gauche à droite (LTR). D’autres langues, telles que l’arabe et l’hébreu, nécessitent une disposition RTL (droite à gauche). La disposition de la fenêtre s’applique au texte, mais affecte également les autres éléments GDI de la fenêtre, notamment les bitmaps, les icônes, l’emplacement de l’origine, les boutons, les contrôles d’arborescence en cascade et si la coordonnée horizontale augmente à mesure que vous allez à gauche ou à droite. Par exemple, une fois qu’une application a défini la disposition RTL, l’origine est positionnée sur le bord droit de la fenêtre ou de l’appareil, et le nombre représentant la coordonnée horizontale augmente à mesure que vous vous déplacez vers la gauche. Toutefois, tous les objets ne sont pas affectés par la disposition d’une fenêtre. Par exemple, la disposition des boîtes de dialogue, des boîtes de message et des contextes d’appareil qui ne sont pas associés à une fenêtre, tels que les contrôleurs de domaine de métafichier et d’imprimante, doit être gérée séparément. Les spécificités de ces éléments sont mentionnées plus loin dans cette rubrique.

Les fonctions de fenêtre vous permettent de spécifier ou de modifier la disposition de la fenêtre dans les versions arabe et hébraïque de Windows. Notez que le passage à une disposition RTL (également appelée mise en miroir) n’est pas pris en charge pour les fenêtres qui ont le style CS_OWNDC ou pour un contrôleur de domaine avec le mode graphique GM_ADVANCED.

Par défaut, la disposition de la fenêtre est de gauche à droite (LTR). Pour définir la disposition de la fenêtre RTL, appelez CreateWindowEx avec le style WS_EX_LAYOUTRTL. Par défaut également, une fenêtre enfant (c’est-à-dire créée avec le style WS_CHILD et avec un paramètre hWnd parent valide dans l’appel à CreateWindow ou CreateWindowEx) a la même disposition que son parent. Pour désactiver l’héritage de la mise en miroir sur toutes les fenêtres enfants, spécifiez WS_EX_NOINHERITLAYOUT dans l’appel à CreateWindowEx. Notez que la mise en miroir n’est pas héritée par les fenêtres détenues (celles créées sans le style WS_CHILD ) ou celles créées avec le paramètre hWnd parent dans CreateWindowEx défini sur NULL. Pour désactiver l’héritage de la mise en miroir pour une fenêtre individuelle, traitez le message WM_NCCREATE avec GetWindowLong et SetWindowLong pour désactiver l’indicateur WS_EX_LAYOUTRTL . Ce traitement s’ajoute à tout autre traitement nécessaire. Le fragment de code suivant montre comment procéder.

SetWindowLong (hWnd, 
               GWL_EXSTYLE, 
               GetWindowLong(hWnd,GWL_EXSTYLE) & ~WS_EX_LAYOUTRTL))

Vous pouvez définir la disposition par défaut sur RTL en appelant SetProcessDefaultLayout(LAYOUT_RTL). Toutes les fenêtres créées après l’appel sont mises en miroir, mais les fenêtres existantes ne sont pas affectées. Pour désactiver la mise en miroir par défaut, appelez SetProcessDefaultLayout(0).

Notez que SetProcessDefaultLayout met en miroir uniquement les contrôleurs de domaine des fenêtres mises en miroir. Pour miroir n’importe quel contrôleur de domaine, appelez SetLayout(hdc, LAYOUT_RTL). Pour plus d’informations, consultez la discussion sur les contextes d’appareil de mise en miroir non associés à Windows, qui se trouve plus loin dans cette rubrique.

Les bitmaps et les icônes d’une fenêtre mise en miroir sont également mises en miroir par défaut. Toutefois, tous ces éléments ne doivent pas être mis en miroir. Par exemple, ceux qui ont du texte, un logo professionnel ou une horloge analogique ne doivent pas être mis en miroir. Pour désactiver la mise en miroir des bitmaps, appelez SetLayout avec le bit LAYOUT_BITMAPORIENTATIONPRESERVED défini dans dwLayout. Pour désactiver la mise en miroir dans un contrôleur de domaine, appelez SetLayout(hdc, 0).

Pour interroger la disposition par défaut actuelle, appelez GetProcessDefaultLayout. En cas de retour réussi, pdwDefaultLayout contient LAYOUT_RTL ou 0. Pour interroger les paramètres de disposition du contexte de l’appareil, appelez GetLayout. En cas de retour réussi, GetLayout retourne un DWORD qui indique les paramètres de disposition par les paramètres du LAYOUT_RTL et les bits LAYOUT_BITMAPORIENTATIONPRESERVED.

Une fois qu’une fenêtre a été créée, vous modifiez la disposition à l’aide de la fonction SetWindowLong . Par exemple, cela est nécessaire lorsque l’utilisateur change la langue de l’interface utilisateur d’une fenêtre existante de l’arabe ou de l’hébreu à l’allemand. Toutefois, lorsque vous modifiez la disposition d’une fenêtre existante, vous devez invalider et mettre à jour la fenêtre pour vous assurer que le contenu de la fenêtre est tous dessiné sur la même disposition. L’exemple de code suivant provient d’un exemple de code qui modifie la disposition de la fenêtre en fonction des besoins :

// Using ANSI versions of GetWindowLong and SetWindowLong because Unicode
// is not needed for these calls

lExStyles = GetWindowLongA(hWnd, GWL_EXSTYLE);

// Check whether new layout is opposite the current layout
if (!!(pLState -> IsRTLLayout) != !!(lExStyles & WS_EX_LAYOUTRTL))
{
    // the following lines will update the window layout

    lExStyles ^= WS_EX_LAYOUTRTL;        // toggle layout
    SetWindowLongA(hWnd, GWL_EXSTYLE, lExStyles);
    InvalidateRect(hWnd, NULL, TRUE);    // to update layout in the client area
}

Dans la mise en miroir, vous devez penser en termes de « proche » et de « loin » au lieu de « gauche » et « droite ». Le fait de ne pas le faire peut entraîner des problèmes. Une pratique de codage courante qui provoque des problèmes dans une fenêtre mise en miroir se produit lors du mappage entre les coordonnées d’écran et les coordonnées du client. Par exemple, les applications utilisent souvent un code similaire à ce qui suit pour positionner un contrôle dans une fenêtre :

// DO NOT USE THIS IF APPLICATION MIRRORS THE WINDOW

// get coordinates of the window in screen coordinates
GetWindowRect(hControl, (LPRECT) &rControlRect);  

// map screen coordinates to client coordinates in dialog
ScreenToClient(hDialog, (LPPOINT) &rControlRect.left); 
ScreenToClient(hDialog, (LPPOINT) &rControlRect.right);

Cela entraîne des problèmes de mise en miroir, car le bord gauche du rectangle devient le bord droit dans une fenêtre mise en miroir, et vice versa. Pour éviter ce problème, remplacez les appels ScreenToClient par un appel à MapWindowPoints comme suit :

// USE THIS FOR MIRRORING

GetWindowRect(hControl, (LPRECT) &rControlRect);
MapWindowPoints(NULL, hDialog, (LPPOINT) &rControlRect, 2)

Ce code fonctionne car, sur les plateformes qui prennent en charge la mise en miroir, MapWindowPoints est modifié pour permuter les coordonnées des points gauche et droit lorsque la fenêtre cliente est mise en miroir. Pour plus d’informations, consultez la section Remarques de MapWindowPoints.

Une autre pratique courante qui peut entraîner des problèmes dans les fenêtres mises en miroir consiste à positionner des objets dans une fenêtre cliente à l’aide de décalages dans les coordonnées d’écran au lieu des coordonnées client. Par exemple, le code suivant utilise la différence de coordonnées d’écran comme position x dans les coordonnées client pour positionner un contrôle dans une boîte de dialogue.

// OK if LTR layout and mapping mode of client is MM_TEXT,
// but WRONG for a mirrored dialog 

RECT rdDialog;
RECT rcControl;

HWND hControl = GetDlgItem(hDlg, IDD_CONTROL);
GetWindowRect(hDlg, &rcDialog);             // gets rect in screen coordinates
GetWindowRect(hControl, &rcControl);
MoveWindow(hControl,
           rcControl.left - rcDialog.left,  // uses x position in client coords
           rcControl.top - rcDialog.top,
           nWidth,
           nHeight,
           FALSE);

Ce code est parfait lorsque la fenêtre de boîte de dialogue a une disposition de gauche à droite (LTR) et que le mode de mappage du client est MM_TEXT, car la nouvelle position x dans les coordonnées du client correspond à la différence entre les bords gauche du contrôle et la boîte de dialogue dans les coordonnées de l’écran. Toutefois, dans une boîte de dialogue mise en miroir, la gauche et la droite sont inversées. Vous devez donc utiliser MapWindowPoints comme suit :

RECT rcDialog;
RECT rcControl;

HWND hControl - GetDlgItem(hDlg, IDD_CONTROL);
GetWindowRect(hControl, &rcControl);

// MapWindowPoints works correctly in both mirrored and non-mirrored windows.
MapWindowPoints(NULL, hDlg, (LPPOINT) &rcControl, 2);

// Now rcControl is in client coordinates.
MoveWindow(hControl, rcControl.left, rcControl.top, nWidth, nHeight, FALSE)

Boîtes de dialogue et boîtes de message de mise en miroir

Les boîtes de dialogue et les boîtes de message n’héritent pas de la disposition. Vous devez donc définir la disposition explicitement. Pour miroir une boîte de message, appelez MessageBox ou MessageBoxEx avec l’option MB_RTLREADING. Pour mettre en page une boîte de dialogue de droite à gauche, utilisez le style étendu WS_EX_LAYOUTRTL dans la structure de modèle de boîte de dialogue DLGTEMPLATEEX. Les feuilles de propriétés sont un cas particulier de boîtes de dialogue. Chaque onglet étant traité comme une boîte de dialogue distincte, vous devez inclure le style WS_EX_LAYOUTRTL dans chaque onglet que vous souhaitez mettre en miroir.

Mise en miroir des contextes d’appareil non associés à une fenêtre

Les contrôleurs de domaine qui ne sont pas associés à une fenêtre, tels que les contrôleurs de domaine de métafichier ou d’imprimante, n’héritent pas de la disposition. Vous devez donc définir la disposition explicitement. Pour modifier la disposition du contexte de l’appareil, utilisez la fonction SetLayout .

La fonction SetLayout est rarement utilisée avec les fenêtres. En règle générale, les fenêtres reçoivent un contrôleur de domaine associé uniquement lors du traitement d’un message WM_PAINT . Parfois, un programme crée un contrôleur de domaine pour une fenêtre en appelant GetDC. Dans les deux cas, la disposition initiale du contrôleur de domaine est définie par BeginPaint ou GetDC en fonction de l’indicateur de WS_EX_LAYOUTRTL de la fenêtre.

Les valeurs retournées par GetWindowOrgEx, GetWindowExtEx, GetViewportOrgEx et GetViewportExtEx ne sont pas affectées par l’appel de SetLayout.

Lorsque la disposition est RTL, GetMapMode retourne MM_ANISOTROPIC au lieu de MM_TEXT. L’appel de SetMapMode avec MM_TEXT fonctionne correctement ; seule la valeur de retour de GetMapMode est affectée. De même, l’appel de SetLayout(hdc, LAYOUT_RTL) lorsque le mode de mappage est MM_TEXT entraîne le passage du mode de mappage signalé à MM_ANISOTROPIC.

Destruction de fenêtre

En général, une application doit détruire toutes les fenêtres qu’elle crée. Pour ce faire, il utilise la fonction DestroyWindow . Lorsqu’une fenêtre est détruite, le système masque la fenêtre, si elle est visible, puis supprime toutes les données internes associées à la fenêtre. Cela invalide le handle de fenêtre, qui ne peut plus être utilisé par l’application.

Une application détruit la plupart des fenêtres qu’elle crée peu après leur création. Par exemple, une application détruit généralement une fenêtre de boîte de dialogue dès que l’application dispose d’une entrée suffisante de la part de l’utilisateur pour poursuivre sa tâche. Une application finit par détruire la fenêtre main de l’application (avant de se terminer).

Avant de détruire une fenêtre, une application doit enregistrer ou supprimer toutes les données associées à la fenêtre, et libérer toutes les ressources système allouées à la fenêtre. Si l’application ne libère pas les ressources, le système libère toutes les ressources non libérées par l’application.

La destruction d’une fenêtre n’affecte pas la classe de fenêtre à partir de laquelle la fenêtre est créée. De nouvelles fenêtres peuvent toujours être créées à l’aide de cette classe, et toutes les fenêtres existantes de cette classe continuent de fonctionner. La destruction d’une fenêtre détruit également les fenêtres descendantes de la fenêtre. La fonction DestroyWindow envoie d’abord un message WM_DESTROY à la fenêtre, puis à ses fenêtres enfants et à ses fenêtres descendantes. De cette façon, toutes les fenêtres descendantes de la fenêtre en cours de destruction sont également détruites.

Une fenêtre avec un menu de fenêtre reçoit un message WM_CLOSE lorsque l’utilisateur clique sur Fermer. En traitant ce message, une application peut inviter l’utilisateur à confirmer avant de détruire la fenêtre. Si l’utilisateur confirme que la fenêtre doit être détruite, l’application peut appeler la fonction DestroyWindow pour détruire la fenêtre.

Si la fenêtre détruite est la fenêtre active, les états actif et focus sont transférés vers une autre fenêtre. La fenêtre qui devient la fenêtre active est la fenêtre suivante, comme déterminé par la combinaison de touches ALT+ÉCHAP. La nouvelle fenêtre active détermine ensuite quelle fenêtre reçoit le focus du clavier.