TN040 : Redimensionnement sur place et zoom MFC/OLE
[!REMARQUE]
La note technique suivante n'a pas été modifiée depuis si c'était première inclus dans la documentation en ligne.Par conséquent, certaines procédures et rubriques peuvent être obsolètes ou incorrects.Pour obtenir les informations les plus récentes, il est recommandé que vous trouviez la rubrique d'intérêt dans l'index de la documentation en ligne.
Cette remarque vous explique les problèmes concernant la modification sur place et comment un serveur doit accomplir zoom correct et redimensionnement sur place.Avec l'activation sur place, le concept WYSIWYG est un peu plus pris en ce sens que les conteneurs et les serveurs coopèrent les uns avec les autres, et interprète en particulier la notion de spécification pratiquement de la même façon.
En raison de l'interaction proche entre un conteneur et une activation sur place de prise en charge du serveur il existe un nombre quelconque d'attentes de l'utilisateur qui doit être conservé :
L'affichage de présentation (métafichier dessiné dans la substitution d' COleServerItem::OnDraw ) doit avoir exactement les mêmes que lorsqu'elle est dessinée pour la modification (sauf que les outils de modification ne sont pas visible).
Lorsque le conteneur effectue un zoom, la fenêtre de serveur doit aussi !
Le conteneur et le serveur doivent afficher des objets pour modifier à la même métrique.Cela signifie qui utilise un mode de mappage en fonction de le nombre de pixels par pouce logiques — pixels par pouce non physiques, en affichant sur le périphérique d'affichage.
[!REMARQUE]
Étant donné que l'activation sur place s'applique uniquement aux éléments qui sont incorporés (non lié), zoom s'applique uniquement aux objets incorporés.Vous constaterez des API dans les deux COleServerDoc et COleServerItem utilisés pour effectuer un zoom.La raison de cette dichotomie est que seules les fonctions qui s'appliquent aux éléments liés et incorporés sont dans COleServerItem (cela vous permet d'avoir une implémentation courante) et les fonctions qui sont valides pour les objets incorporés sont situées dans la classe d' COleServerDoc (du point de vue du serveur, il s'agit document incorporé).
La plupart de la charge est placée dans l'implémenteur de serveur, car le serveur doit tenir compte du facteur de zoom du conteneur et modifier son interface de modification selon le cas.Mais comment le serveur détermine-il le facteur de zoom que le conteneur utilise ?
Prise en charge MFC pour effectuer un zoom
Le facteur de zoom actuel peut être déterminé en appelant COleServerDoc::GetZoomFactor.Appeler cette méthode lorsque le document n'est pas actif sur place aura toujours traduire par un facteur de zoom 100% (ou le taux de 1:1).L'appeler pendant qu'actif sur place peut retourner une valeur différente de 100%.
Pour obtenir un exemple de zoom correctement consultez l'exemple de liaison et incorporation d'objets MFC HIERSVR.Zoom dans HIERSVR est compliqué par le fait qu'il affiche le texte, et le texte en général, ne monte pas de façon linéaire (les indicateurs, les conventions typographiques, les largeurs de conception, et les hauteurs tous compliquent la planification).Toujours, HIERSVR est une référence appropriée pour implémenter correctement zoom, de même qu'MFC SCRIBBLE d'instruction (étape 7).
COleServerDoc::GetZoomFactor détermine le facteur de zoom en fonction de plusieurs métriques différente fournie à partir de le conteneur ou de l'implémentation de vos classes d' COleServerItem et d' COleServerDoc .En résumé, le facteur de zoom en cours est déterminé par la formule suivante :
Position Rectangle (PR) / Container Extent (CE)
Le RECTANGLE de POSITION est déterminé par le conteneur.Elle est retournée au serveur pendant l'activation sur place lorsque COleClientItem::OnGetItemPosition est appelé et est mise à jour lorsque le conteneur appelle COleServerDoc::OnSetItemRects du serveur (par un appel à COleClientItem::SetItemRects).
L'AMPLEUR CONTAINER est un peu plus complexe pour calculer.Si le conteneur est appelé COleServerItem::OnSetExtent (avec un appel à COleClientItem::SetExtent), l'AMPLEUR CONTAINER est cette valeur convertie en pixels en fonction de le nombre de pixels par pouce logique.Si le conteneur n'a pas appelé SetExtent (qui est généralement le cas), l'AMPLEUR CONTAINER est la taille retournée à partir de COleServerItem::OnGetExtent.Par conséquent, si le conteneur n'a pas appelé SetExtent, l'infrastructure suppose que s'il faisait le conteneur aurait appelé avec 100% de l'étendue naturelle (la valeur retournée par COleServerItem::GetExtent).Un énoncé une autre façon, l'infrastructure suppose que le conteneur affiche 100% (pas plus, pas moins) de l'élément.
Il est important de noter que bien qu' COleServerItem::OnSetExtent et COleServerItem::OnGetExtent aient des noms similaires, ils ne manipulent pas le même attribut de l'élément.OnSetExtent est appelé pour effectuer le serveur savoir quel nombre d'objet est visible dans le conteneur (indépendamment du facteur de zoom) et OnGetExtent est appelé par le conteneur pour déterminer la taille idéale de l'objet.
En examinant chacune des API concernées, vous pouvez obtenir une image plus de clarté :
COleServerItem::OnGetExtent
Cette fonction doit retourner « la taille naturelle » en unités HIMETRIC de l'élément.La meilleure façon de penser « à la taille naturelle » est de le définir comme la taille qu'elle peut apparaître à l'impression.La taille retournée ici est constante pour le contenu d'un élément particulier (comme le métafichier, qui est une valeur constante pour un élément particulier).Cette taille ne change pas en mode de zoom est appliqué à l'élément.Il généralement ne change pas lorsque le conteneur affecte à l'élément plus ou moins d'espace en appelant OnSetExtent.Un exemple d'une modification peut être celui d'un éditeur de texte simple sans aucune fonction « marge » qui a encapsulé le texte en fonction de la dernière étendue envoyée par le conteneur.Si un serveur est modifié, le serveur doit définir éventuellement le bit d'OLEMISC_RECOMPOSEONRESIZE dans la base de registres (consultez la documentation OLE Kit de développement logiciel pour plus d'informations sur cette option).
COleServerItem::OnSetExtent
Cette fonction est appelée lorsque le conteneur indique « plus ou moins » de l'objet.La plupart des conteneurs n'appellent pas cette opération du tout.L'implémentation par défaut enregistre la dernière valeur reçue du conteneur dans « m_sizeExtent », utilisé dans COleServerDoc::GetZoomFactor en calculant la valeur d'AMPLEUR CONTAINER décrite ci-dessus.
COleServerDoc::OnSetItemRects
Cette fonction est appelée uniquement lorsque le document est actif sur place.Elle est appelée lorsque le conteneur met à jour l'un ou l'autre la position ou découpage de l'élément appliquée à l'élément.Le RECTANGLE de POSITION, comme décrit ci-dessus, fournit le numérateur pour le calcul de facteur de zoom.Un serveur pouvez demander que la position d'éléments est modifiée en appelant COleServerDoc::RequestPositionChange.Le conteneur peut ou ne pas répondre à cette demande en appelant OnSetItemRects (avec un appel à COleServerItem::SetItemRects).
COleServerDoc::OnDraw
Il est important de savoir que le métafichier créé en substituant d' COleServerItem::OnDraw produit exactement le même métafichier, quel que soit le facteur de zoom actuel.Le conteneur dimensionnera métafichier selon le cas.Cette distinction est importante entre OnDraw de la vue et OnDrawde l'élément du serveur.La vue gère zoom, l'élément crée simplement un métafichier zoomable et les feuilles il jusqu ' à le conteneur pour ce zoom approprié.
Le meilleur moyen d'assurer que votre serveur se comporte correctement est d'utiliser l'implémentation d' COleServerDoc::GetZoomFactor si votre document actif sur place.
Prise en charge MFC pour le redimensionnement sur place
MFC implémente pas l'interface visuelle de redimensionnement comme décrit dans la spécification OLE 2.L'interface utilisateur est prise en charge par la classe d' COleResizeBar , un message WM_SIZECHILDpersonnalisés, et une gestion spéciale de ce message dans COleIPFrameWnd.
Vous pouvez souhaiter implémenter la gestion différente de ce message que celles fournies par l'infrastructure.Comme décrit ci-dessus, l'infrastructure de les résultats de redimensionner sur place jusqu ' à le conteneur — le serveur répond à la modification du facteur de zoom.Si le conteneur réagit en définissant l'AMPLEUR CONTAINER et le RECTANGLE de POSITION pendant le traitement de son COleClientItem::OnChangeItemPosition (appelé à la suite d'un appel à COleServerDoc::RequestPositionChange) tandis que le sur place redimensionnent génèrent l'apparence « plus ou moins » de l'élément dans la fenêtre de modification.Si le conteneur réagit en définissant simplement le RECTANGLE de POSITION pendant le traitement d' COleClientItem::OnChangeItemPosition, le facteur de zoom change et l'élément sera affiché « zoom dans ou. »
Un serveur peut contrôler (à un certain niveau) ce qui se produit pendant cette négociation.Une feuille de calcul, par exemple peut choisir d'afficher plus ou moins cellules lorsque l'utilisateur redimensionne la fenêtre en modifiant l'élément sur place.Un traitement de texte peut choisir de modifier les « marges de page » et sont les mêmes que la fenêtre et le rewrap le texte à la nouvelle marge.Les serveurs implémentent ce problème en modifiant l'étendue naturelle (taille retournée à partir de COleServerItem::OnGetExtent) lors de le redimensionnement est passé.Cela provoque le RECTANGLE de POSITION et l'AMPLEUR CONTAINER à la modification par le même volume, ce qui provoque le même facteur de zoom, mais une plus grande ou plus petite zone de rendu.En outre, plus ou moins de le document sont visibles dans le métafichier généré par OnDraw.Dans ce cas, le document lui-même change lorsque l'utilisateur redimensionne l'élément, au lieu de la zone de rendu.
Vous pouvez implémenter le redimensionnement personnalisé et encore tirer parti de l'interface utilisateur fournie par COleResizeBar en substituant le message de WM_SIZECHILD dans votre classe d' COleIPFrameWnd .Pour plus d'informations sur les détails de WM_SIZECHILD, consultez note technique 24.