- 7 minutes to read
The WindowsUI View offers you a variety of content containers to build separate application screens (modules) with a native Windows Modern look. Using the container hierarchy concept, you can then easily utilize all these containers to create complete app navigation. This document contains detailed information about all the container types available.
Content Containers forTileobjects
Content Containers forDocumentobjects
Any container can be populated at design time using the “Layout” tab of the WindowsUI Designer. To do the same in code, modify the required container’s Items collection by calling Add, AddRange, Insert, Clear and other methods. The table below lists other concepts that are shared among all WindowsUI View containers.
Limitations and other notes
Displayed automatically for child containers.
Can be manually redrawn by handling the WindowsUIView.CustomDrawBackButton event.
Custom container buttons
Cannot be added to Page Group containers
Tile Containers (objects of the TileContainer class) display tiles (the Tile class). This container is a replica of the standalone Tile Control shaped as a child container for the WindowsUI View - it fully supports such TileControl features as tile grouping, dragging tiles at runtime, animated ‘live’ tiles, etc. The figure below illustrates a TileContainer with two groups.
This container type is the only one that can be created by the View automatically. This happens when you add new documents using the WindowsUI Designer - the view will automatically create tiles for each new document added, and a Tile Container to store these tiles. Both tiles and their container can be safely removed if you do not need them.
In a typical Windows Modern-inspired application, the Tile Container is the topmost container, the first application screen your end-users see. To specify what application screens will be visible as users click these tiles, use the ActivationTarget property. The View provides two ActivationTarget properties.
- TileContainer.ActivationTarget - gets or sets the screen to which any tile will take your end-users upon clicking. This setting also does the following: consider an app with a start-up TileContainer and one child multi-document container (e.g., a Page Group). Then, after you set your PageGroup as an activation target for the TileContainer, clicking any tile will activate this PageGroup. However, the PageGroup should not just appear as is, its currently selected document should match the clicked tile. Normally you would expect to manually code a custom logic that would switch active PageGroup tabs depending on which tile was clicked. The WindowsUI View spares you from this coding, and setting the ActivationTarget is all you need to do - the target container will be shown with the required document already focused.
- Tile.ActivationTarget - specifies a container specific to this tile only. If not set, the container assigned to the TileContainer.ActivationTarget property will be shown.
- If none of these two properties were set manually, end-users will be taken to automatically created Page containers, each hosting a document related to the clicked tile (the Tile.Document property).
The default ITileContainerDefaultProperties.ItemSize property value equals 180, which differs from the default TileControl.ItemSize property value of 120. This setting makes Tiles within a Tile Container larger than Tiles within a Tile Control.
Example: How To: Create a TileContainer
PageGroup is a Windows Modern-inspired tab container with multiple flat tabs (documents) that display their headers at the top right corner. End-users can click these headers to browse through the tabs. The figure below illustrates an example.
Tab headers display text strings stored within related documents’ BaseDocument.Header properties. If a document has an image assigned to the BaseDocument.Image property, it will also be shown within the tab header.
Example: How To: Create a PageGroup Container
The TabbedGroup container is very similar to the Page Group container. It also contains multiple Documents, and only one can be displayed at a time. End-users also use Document headers to navigate through Documents. However, unlike the Page Group container, Document headers within a Tabbed Group can be presented differently: either as standard tab headers or as tiles. The image below illustrates a Tabbed Group container with four child Documents. Each Document displays a customized tile as its header.
To choose the desired header style, use the ITabbedGroupDefaultProperties.HeaderStyle property. If you select tiles, use properties that start with “Tile” to customize them (e.g., the ITabbedGroupDefaultProperties.TileSize or ITabbedGroupDefaultProperties.TileContentMargin properties). Tiles will automatically receive their text and image content from related documents’ BaseDocument.Header and BaseDocument.Image properties respectively.
A SlideGroup displays all its child documents side-by-side in a single column or row, depending on the IContentContainerDefaultProperties.Orientation property value. End-users can scroll through this container by dragging its white space or using the embedded scroll bar. The figure below illustrates a sample SlideGroup with horizontal orientation.
By default, each document occupies 66% of the parent Slide Group. This ratio persists even when end-users resize the form. To modify this ratio, use the ISlideGroupDefaultProperties.ItemLengthRatio property. You can also disable the relative sizing and assign an explicit size value to each document. To do so, use the ISlideGroupDefaultProperties.ItemLength property.
Document headers displayed above each document are clickable elements that take your end-users to a separate detail screen - a container that hosts and displays only one document (the figure below).
While browsing this detail screen, a user can quickly surf to another document without going back to the main screen. In order to do so, a user should right-click inside the detail screen and click a navigation button on the upper navigation bar which will pop up. The same navigation buttons are shown on the upper navigation bar for the main Slide Group screen.
Finally, the Slide Group provides a screen with tiles. Each activates a button that navigates a user back to the main screen and slides it to the related document. This screen is called the overview screen and can be accessed through the main Slide Group screen by clicking a corresponding navigation bar button.
To customize overview screen tiles, use the properties accessible through the SlideGroup.OverviewContainerProperties group.
The SplitGroup container splits its content area into multiple equal panes, each containing a child document. Splitters located between neighboring panes allow end-users to resize documents at runtime. The figure below illustrates a sample Split Group container.
To resize child Split Group documents in code, call the DocumentGroup.SetLength method to pass the required size value to the specific document.
Split Group containers also provide overview and detail screens like Slide Groups do. The list below enumerates minor differences between these secondary screens in Slide and Split groups.
- Split Groups do not display document headers above document content. Thus, the only remaining way to navigate to a detail screen at runtime is to use the upper navigation bar.
- A Slide Group overview screen returns a user to the main container screen and scrolls it to the required document. Split Groups in turn display all documents at once, so there is no point in similar overview screen behavior. Instead, Split Group overview screens bring end-users to detail screens with related documents.
Detail screens for Slide and Split Group containers are actually pages with different documents within.
Example: How To: Create a Page Container