US 20060253796 A1
Described is a method and system by which a computer program window is sized based on the content to display. The window may automatically resize itself as content changes. When laying out an element tree of elements that contain the content, the elements provide desired size information to a parent container, and so on, up to the root element (e.g., a window). If a window property is set to size to the content, a window size is computed during layout, having a height and/or width based on the child elements plus X and Y deltas for a window non-client area and borders. Logic attached to window message handling controls changes to the content/window, such as to automatically resize for changed content, and to selectively turn off or persist the size to content property. Sizing to content may be programmatically limited to one dimension, with the other dimension fixed.
1. In a computing environment, a method comprising:
obtaining size information from an element in an element tree based on size of content to render; and
sizing a window to the size information.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. At least one computer-readable medium having computer-executable instructions, which when executed perform the method of
8. At least one computer-readable medium having computer-executable instructions, which when executed perform steps, comprising:
sizing a window based on the content to be rendered in that window; and
automatically resizing the window when the content changes.
9. The computer-readable medium of
10. The computer-readable medium of
11. The computer-readable medium of
12. The computer-readable medium of
13. The computer-readable medium of
14. The computer-readable medium of
15. The computer-readable medium of
16. The computer-readable medium of
17. The computer-readable medium of
18. In a computing environment, a system comprising:
an element tree of elements, at least one of the elements corresponding to content for rendering;
a window element in the element tree, the window element above each element that corresponds to the content for rendering, and the window element having a property that determines whether a rendered window corresponding to the window element will be sized based on the content's size;
a layout mechanism that provides size information to the window element based on the content, such that the rendered window sizes to the content when the property is in a state in which the rendered window is to size to the content; and
a message handling mechanism that processes window messages to determine whether to resize the rendered window.
19. The system of
20. The system of
The invention relates generally to computer systems, and more particularly to the display of graphical and other video information for programs on computer systems.
The term “layout” in user interface application platforms refers to the sizes and positions of user interface elements, such as text boxes, buttons, image boxes, and so forth. Layout has traditionally been a very difficult problem to solve. For example, layout needs logic to handle dynamic changes.
By way of example, consider when content that is currently being displayed changes in some way. This may be a result of user interaction with the window, a locale change where the user interface elements remain essentially the same but the language (and thus the text content) changes, an automatically timed or otherwise triggered update to the content, and so forth.
Heretofore, content that did not fit within a current window was handled in a number of ways to make it or some portion of it fit, including when the content changed. For example, if it was text content that changed, the text content may automatically wrap to fit in the current element (e.g., text box) within the window. For text that was unable to wrap, or for image data and the like, clipping is another alternative, including having vertical and/or horizontal scrollbars provided as necessary to allow the user to interactively view the entire content. Resizing the content (e.g., via scaling) to fit is another option.
While these solutions all provide a way to present content to users, there are drawbacks to each. For example, a user interface scene designer may not realize that a locale change will cause an element's (e.g., button's) text to not fit in the element when translated. Even in systems in which the elements can automatically resize to fit the text, this resizing may no longer fit the window. For example, after resizing, even a simple dialog window may require that the user scroll in order to view and interact with an item (e.g., a button). What is needed is another way for scene designers to present content to the users that overcomes these and other drawbacks.
Briefly, the present invention is directed towards a method and system by which a window is sized based the content that is being displayed. This may include having the window automatically resize itself as content changes.
In one implementation, a layout system is described in which content corresponds to elements in an element tree. As part of layout, the elements provide desired size information to a parent container, and so on, up to the root element (e.g., a window). In this manner, sizing information ultimately is obtained by a top-level window element that can adjust its size. A window property associated with the window handle (e.g., SizeToContent on HwndSource) may be selectively set to have the window resize to content when the property is in the correct state, as specified by a program, or possibly by the user.
Thus, for user interface functionality, a program receives a handle to a window for rendering user interface elements, wherein a window can include a main program window, a dialog, a pop-up and so forth. The program can set the SizeToContent property on the window. If set, the window will initially size to the content based on the size of each child element beneath the window element, and the window will resize as necessary as the content changes, and thus the element's desired size changes, for various reasons. To this end, when layout decisions are made, as performed by the elements and/or in conjunction with a layout system, the elements in the element tree are configured.
In general, at layout time, a panel or other child element of the window asks each of its child elements in a measure phase what the desired size of the child is, and possibly also receives positioning data. The children are thus able to size and resize themselves based on their current content, which allows for dynamically changing content. A child of the window, such as a panel, analyzes the desired sizes of its children and changes sizes and positions as necessary, e.g., based upon maximum and minimum size constraints. The panel returns a desired size to the window, whereby the window adjusts its size to comply with the desired size of the content. A window size is thus computed, having a height and/or width based on the child elements to be rendered in the window, plus possibly a small delta X for the window side borders, and a delta Y for a window caption area and a bottom border. The delta X and Y are based on the style of the window that is currently in use, and may be zero. If the requested size exceeds the maximum that the window can provide, vertical and/or horizontal scrollbars may be automatically provided.
The elements are then arranged in an arrange phase, after which representations of the elements at their arranged positions and with their arranged sizes are rendered. If any content's size changes, the content's containing element informs its parent in the tree, and so on up to the window element, whereby the window automatically readjusts its size to fit the changed content size, (subject to maximum and minimum constraints).
The window can be configured by the scene designer to resize both vertically and horizontally, or only in one horizontal or vertical dimension. Thus, a scene designer can specify a fixed height with a size-to-content width, a fixed width with a size-to content height, or both a size-to-content width and size-to-content width height.
In one implementation, the SizeToContent property is persisted in association with the window handle, so that, for example, if the window is minimized and then restored, the window still behaves the same way. Similarly, the size-to-content feature remains active if the window's style changes. The SizeToContent property also overrides other programmatic window size management function calls, unless the scene author explicitly turns off the SizeToContent property off. Certain types of user interaction to manually change the size, e.g., by maximizing the window or resizing by dragging the window edge or corner turns off the size to content property, giving a user the ability to manually size a window. An option (e.g., button) to restore the size-to-content feature via manual interaction may be provided. Logic in a hook of the window message handling mechanism implements the rules that properly handle changes to the content and/or the window, providing a window that sizes to content in an intelligent way.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
Exemplary Operating Environment
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention also may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 110. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Size to Content Windows
The present invention is generally directed towards resizing a window to fit content, when specified by a program, including if the content changes. To this end, the present invention leverages layout system functionality in which scene designer-specified elements communicate desired size information to parent elements in an element tree, whereby sizing information ultimately is obtained by a top-level window element that can adjust its size. As will be understood, numerous ways to implement the present invention are feasible, and only some of the alternatives are described herein. For example, the present invention is primarily described below with reference to a window property associated with the window handle (e.g., SizeToContent on HwndSource) that may be selectively set to have the window resize to content as specified by a program when the property is in the correct state. However, it is also straightforward to have a mechanism that can set the property independent of and external to program control. Moreover, it is alternatively feasible to not have such a property, but instead allow a program request either a size-to-content window or a regular window. Still further, the present invention may function with any window handle-based controls and/or content. As such, the present invention is not limited to any particular examples used herein, but rather may be used various ways that provide benefits and advantages in computing in general.
Once layout decisions are made, performed by the elements and/or in conjunction with a layout system 308, the elements in the element tree 306 are properly configured. A renderer component 310 (of a media integration layer, or MIL) takes data from the element tree 306, including the sizes and positions, drawing primitives and other information, and renders the user interface elements to a suitable display. For example, in
In the implementation of
In accordance with an aspect of the present invention, for sizing a window to the content, the window analyzes the desired size of its child (the panel), which likewise may be subject to the minimum and maximum constraints. In this manner, the window adjusts its size to comply with the desired size of the content. Note that a child window may set the size of its container window (e.g., a browser control) so that the container window sizes to content. Further, note that if the requested size exceeds the maximum that the window can provide, vertical and/or horizontal scrollbars may be automatically provided. The elements are then arranged in an arrange phase, after which representations of the elements at their arranged positions and with their arranged sizes are then rendered.
By way of an example, consider that the child elements of
In this example, the panel/window client area's height is determined by the height of the text box area 504 (e.g., in pixels) plus the height of button A's area 506. The width of the panel/client area is determined by the width of the button A's area 506 plus the width of the button B's area 508. The image area 510 is centered in the remaining panel area in this example, but may be otherwise aligned.
A window size is thus computed, having a width of the total of the button widths, plus a small delta X for the window side borders, and a total height of the text box height plus the button height, plus a delta Y for the window caption area and a bottom border (the window side and bottom borders and the caption area comprise to form the window non-client area). The delta X and Y are based on the style of the window that is currently in use. Note that if the window style changes such that there are different (or no) borders and/or a window non-client area, the window size is recalculated based on the style change, as described below.
In keeping with the present invention, the size of the dialog window 612 adjusts based on the content currently being shown. In this example, the increased size needed for uniform buttons causes the width of the dialog window 612 b to be increased relative to the dialog window 612 a . Note that because the text wrapped differently as a result of the horizontal increase, the height of the dialog window 612 b has decreased relative to that of the dialog window 612 a.
It should be noted that a scene designer can specify which dimension or dimensions in which a window automatically resizes to content. Thus, a scene designer can specify a fixed height with a size-to-content width, a fixed width with a size-to content height, or both a size-to-content width and size-to-content width height. For example, to size both width and height, a developer provides a command such as
If set in this way, subsequent commands that change the width or height are ignored while the SizeToContent property is on. However, if SizeToContent is turned on for only one dimension, the developer is free to change the other dimension at any time.
In this manner, the developer has the flexibility to treat one dimension differently from the other, which works well with certain scenarios, such as task panes. Note that in one implementation, the default value for the SizeToContent property is Manual, which means not to SizeToContent unless explicitly specified. Thus, the developer has to specify each dimension for which SizeToContent is desired.
As can be seen from the above examples, the window sizes based upon the content size, such that the entire content is visible, without any blank area. If any content's size changes, the content's containing element informs its parent in the tree, and so on up to the window element, whereby the window automatically readjusts its size to fit the changed content size, (subject to maximum and minimum constraints).
As described above, sizing the window to content is highly advantageous for localization scenarios in which content size may change from locale to locale. The present invention also provides benefits in navigation scenarios. For example, when the application navigates to different sized pages, the window will automatically resize itself to display the new page. Animation can also benefit from sizing the window to content in accordance with the present invention, e.g., when the size of content is an animated characteristic, the window's size will also be automatically animated. Note that the content may be changed in any way, e.g., a font size for text can grow or shrink even though the text itself does not change.
In one implementation, the SizeToContent property is persisted in association with the window handle, so that, for example, if the window is minimized and then restored, the window still behaves the same way. Similarly, the size-to-content remains active if the window's style changes. The SizeToContent property also overrides other window size management function calls, e.g., made by the program, including SetWindowPos, MoveWindow, SetWindowLong and ShowWindow.
If programmatic resizing of a window is desired, the scene author can explicitly turn the SizeToContent property off, and then resize. If not turned off for a given dimension, the SizeToContent property on a window thus overrides other program-specified width and/or height properties, and is restricted by maximum and minimum width and height properties.
Another way that the SizeToContent property is turned off is after certain types of user interaction manually change the size, e.g., by maximizing the window or resizing by dragging the window edge or corner. This is because a user is given the ability to manually size a window.
Turning to an explanation of the present invention, the content inside the window needs to layout when the content is first rooted inside the window, and/or when the scene designer sets the SizeToContent property after rooting the content in the window. Note that this may be based on user interaction, e.g., size to content is turned active when the user clicks a button. Layout of the content also takes place when the content's size changes after being rooted in the window.
In the event that the end user resizes the window (other than minimizing the window), the SizeToContent property is turned off, essentially giving the user the ability to manually override the automatic sizing. Note that if the program calls window sizing management APIs such as SetWindowPos, layout is updated only when SizeToContent is off.
As represented in
As represented by step 806, a notification is received when the size the SizeToContent property is set. Note that this may be because the scene designer has set the SizeToContent property after rooting the content in the window. Again, if size to content is on, as evaluated via the SizeToContent property at step 808, the content is asked for its desired size at step 810.
Essentially the content's element is called during layout, and the process waits for a return response (layout is asynchronous). A content size changed event is generally represented in
To control when to resize and when to turn the property on and off, variuos window messages are processed. To this end, in one implementation, the window and HwndSource's functionality build on top of a window handle (hwnd), and the hwnd window's WinProc is hooked to process the messages of interest with respect to sizing to content. In this example implementation, generally represented in
More particularly, to implement size to content functionality, any WM_SYSCOMMAND, WM_SIZING, WM_WINDOWPOSCHANGING and WM_SIZE messages are processed in the hook. For WM_SYSCOMMAND, (where WPARAM wParam and LPARAM lParam are parameters), represented by the leftmost branch in
A WM_SIZING (WPARAM wParam LPARAM lparam) notification message, represented by the second-to-leftmost branch below the switch statement, is received by a window when the end user is resizing. It is only fired when it is user-initiated resizing, and it is the first notification that fires. This notification message is not received when it is the application program code programmatically changing the size (using win32 APIs or other presentation platform sizing APIs), whereby when received it is known that the resizing is from the end user. The SizeToContent property is thus turned off at step 1004 when this notification is received, so as to be consistent with allowing the user to manually control the window size. Note that in one implementation, this is not per dimension; that is, if only width (not height) is sizing to content, the SizeToContent property is turned off even when the user only manually changes the height. A per-dimension alternative is straightforward to implement, however.
A WM_WINDOWPOSCHANGING (WPARAM wParam LPARAM lparam) message (the second to rightmost branch of the switch statement) is received by a window when its size, position, style, or place in the Z-order is in process of changing as a result of either a call of SetWindowPos or other window management function, or in the event of an end user resizing the window. If it is the end user's resizing, the manual action to change the size is respected, and SizeToContent has already been turned off via the WM_SIZING notification that was previously received (note that the WM_SIZING notification is received and processed first). WM_GETMINMAXINFO is a similar event, but it is not sent if the window size does not change. For example, if the size of the window does not change, but the style changes, the window's non-client area may become smaller; thus, the process needs to make sure the client area persists the SizeToContent behavior.
In general, as represented via step 1006, if the message is a result of the window sizing management function call made in
More particularly, with respect to a possible style change, in the event that WM_WINOWPOSCHANGING was sent as a result of a style change, a WM_STYLECHANGED message is sent beforehand. The style bits, obtained by calling GetWindowStyle, are already updated to reflect the new style. AdjustWindowRectEx is called to get the size for this new style.
If lParam's flag is SWP_NOSIZE, it means it is a style or position change. If there is a style change and the window non-client area size changes as a result of the style change, the process reverts the SWP_NOSIZE flag and sets lParam's cx and cy with the content's desired size (Step 1010).
If the lParam's flag is not SWP_NOSIZE, it means it is a size change; the process thus updates lParam's cx and cy with content's desired size. This is represented in
The rightmost branch of the switch statement represents processing the WM_SIZE (WPARAM wParam LPARAM lparam) message, which is received at a window when its size has been changed. If it is not from the window sizing management function call made by the process of
In this manner, the present invention provides a window that sizes to content in an intelligent way, subject to constraints and logic/rules that properly handle changes to the content and/or the window. Note that maximum and minimum constraints may be based on a multiple monitor scenario, and if so, the present invention will allow content to size across multiple monitors if necessary. Scrollbars may be automatically added if the constraints limit the client area to something less than requested.
As can be seen from the foregoing detailed description, there is described a method and system that provide for sizing a window to content. The sizing allows a scene designer to automatically have elements fit within a window, and handles dynamic changes. The method and system thus provide numerous benefits and advantages needed in contemporary computing.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.