Table 12-1 lists the styles you can pass to the wxTreeCtrl constructor or Create function; also refer to the available styles for wxWindow in Table 4-1.

wxTreeCtrl generates wxTreeEvent events, listed in Table 12-2. These events propagate up the window parent-child hierarchy.

These are the important wxTreeCtrl functions.

Use AddRoot to create the first item and then AppendItem, InsertItem, or PrependItem to add subsequent items. Remove an item with Delete, clear all items with DeleteAllItems, or remove all of an item’s immediate descendants with DeleteChildren.

Set an item’s label with SetItemText; you can change the label’s appearance with SetItemTextColour, SetItemBackgroundColour, SetItemBold, and SetItemFont.

If you show images in your tree items, use SetImageList or AssignImage List to associate a wxImageList with the tree control. Each item can show an image for each of the possible item states: wxTreeItemIcon_Normal, wxTreeItemIcon_Selected, wxTreeItemIcon_Expanded, and wxTreeItemIcon_Selected Expanded. Use SetItemImage to pass an index into the tree control’s image list and an optional state. If only the image for the normal state is specified, it will be used for the other states, too.

Scroll an item into view with ScrollTo, or use EnsureVisible if items may need to be expanded to show the desired item. Expand shows the children of an item. Collapse an item that has children with Collapse or CollapseAndReset: the latter also removes the children. This is useful if you’re implementing a tree control with a very large number of items. You may want to add items only when they are visible—that is, when you process an EVT_TREE_ITEM_EXPANDING event. In this case, you will need to use SetItemHasChildren to provide visual feedback that an unexpanded item has children, even when it doesn’t.

You can select or deselect an item with SelectItem. For a single-selection tree, you can get the currently selected item with GetSelection. If there is no selection, it returns an invalid wxTreeItemId, such that a call to wxTree ItemId::IsOk returns false. For a multiple-selection tree, retrieve all the selections with GetSelections by passing a wxArrayTreeItemItemIds reference to the function. Unselect removes the current selection for a single-selection tree, whereas UnselectAll removes all selections from a multiple-selection tree. UnselectItem can be used in a multiple-selection tree to deselect a specific item.

There are several ways to traverse the tree: you can start at the top with GetRootItem and iterate through the children of an item with GetFirstChild and GetNextChild. Find the next and previous siblings of an item with GetNextSibling and GetPrevSibling, determine whether an item has children with ItemHasChildren, and get the parent of an item with GetParent. GetCount returns the total number of items in the tree, and GetChildrenCount counts the number of descendants for the given item.

HitTest is a useful function if you’re implementing drag and drop—it enables you to find the item under the mouse position, together with the part of the item. See the reference manual for the flags returned by HitTest. You can find the bounding rectangle for an item with GetBoundingRect.

For more information on these functions, see the reference manual and the wxTreeCtrl sample in samples/treectrl.

Table 12-3 lists the styles you can pass to the wxListCtrl constructor or Create function. Also refer to the available styles for wxWindow in Table 4-1.

wxListCtrl generates wxListEvent events, described in Table 12-4. These events propagate up the window parent-child hierarchy. Events dealing with a single item return the item index with wxListEvent::GetIndex.

wxListItem is a class you can use to insert an item, set an item’s properties, or retrieve information from an item.

Use SetMask to indicate which properties you want to be taken into account, as described in Table 12-5.

Call SetId to set the zero-based item position, and call SetColumn to set the zero-based column position if the control is in report mode.

Call SetState to set the item state, as listed in Table 12-6.

Call SetStateMask to indicate which states you are modifying. This method uses the same symbols as for SetState.

Call SetText to set the label or header text, and call SetImage to set the zero-based index into an image list.

Call SetData with a long integer argument to associate data with the item.

For columns only, call SetFormat with wxLIST_FORMAT_LEFT, wxLIST_FORMAT_RIGHT, or wxLIST_FORMAT_CENTRE (identical to wxLIST_FORMAT_CENTER). Also for columns only, call SetColumnWidth to set the column’s width.

Other functions set various additional visual properties: SetAlign, SetBackgroundColour, SetTextColour, and SetFont. These don’t require a mask flag to be specified. All wxListItem functions have equivalent accessors prefixed by Get for retrieving information about an item.

Here’s an example of using wxListItem to select the second item, set its text label, and color it red:

As an alternative to using wxListItem, you can set and get properties for an item with wxListCtrl convenience functions such as SetItemText, SetItemImage, SetItemState, GetItemText, GetItemImage, GetItemState, and so on as described in the following.

These are the important wxListCtrl functions.

Call Arrange to arrange the items in icon or small icon view, on Windows only.

Use AssignImageList to associate an image list and have wxListCtrl handle its deletion; use SetImageList if you don’t want wxListCtrl to delete it. Pass wxIMAGE_LIST_NORMAL or wxIMAGE_LIST_SMALL to tell wxListCtrl what set of icons this image list will be used for. GetImageList retrieves a pointer to either list.

InsertItem inserts an item at the specified position in the control. You can pass a wxListItem object having set its member variables. Alternatively, you can pass an item index and a string label, or an item index and an image index, or an item index, a label, and an image index. InsertColumn inserts a column in report view.

ClearAll deletes all items and (in report view) columns, and it generates an all-items deletion event. DeleteAllItems deletes all items but not columns and generates an all-items deletion event. DeleteItem deletes a single item and generates an item deletion event. DeleteColumn deletes a column in report view.

Use SetItem to set information about an item: you can pass a wxListItem object as explained previously, or you can pass an index, column, label, and image index. GetItem can be used to get information about the index specified with wxListItem::SetId.

Call SetItemData with an index and a long data value to associate application-defined data with the item. For most platforms, you can store a pointer in this integer value, but on some platforms, a pointer will not fit into an integer. In these cases, you can use a hashmap to map from integer to object pointer, for example. GetItemData retrieves the item for the given index. Note that if the position of an item moves due to sorting, insertion, or removal, the index of the item may change, but its item data will remain the same, so this is a way of identifying an item.

Use SetItemImage to change the image associated with an item; it takes an item index and an index into the image list.

SetItemState sets the state for the given item; you must supply a state mask to specify which state flags are being changed. See the description for wxListItem in the previous section for more details. GetItemState is used to retrieve the state for a given item.

Use SetItemText to set the item’s label and GetItemText to retrieve the label.

SetTextColour sets the text color for all items, and SetBackgroundColour sets the background color for the control. SetItemTextColour and SetItemBackgroundColour set an individual item’s text and background colors, in report view only. The usual getters are available to retrieve text and background colors.

EditLabel starts editing a label and sends a wxEVT_LIST_BEGIN_LABEL_EDIT event. You can get the current text control used for editing with GetEditControl (Windows only).

Use EnsureVisible if you need a particular item to be visible. ScrollList scrolls by a given number of pixels in each orientation (Windows only). Use RefreshItem or RefreshItems to refresh the appearance of an item or a range of items, particularly when using a virtual list control when the underlying data has changed. GetTopItem returns the index of the topmost visible item when in list or report view.

FindItem is a versatile overloaded function that can be used to search for items with a given label, data, or position. GetNextItem is used to search for an item with the given state (for example, to find all selected items). Use HitTest to find an item at a given point. GetItemPosition returns the position of an item in icon or small icon view in client coordinates, and GetItemRect returns an item’s size and position in client coordinates.

You can change the style of a wxListCtrl dynamically, without having to destroy and re-create it: use SetSingleStyle to set a style such as wxLC_REPORT. Pass false to this function to remove the style.

Use SetColumn in report mode to set information about a column, such as header label and width: see wxListItem in the previous section. Use SetColumnWidth to set a column’s width, as a simpler alternative to SetColumn. You can get column information with GetColumn and GetColumnWidth. Get the number of columns with GetColumnCount (report view only).

Get the number of items in a list control with GetItemCount and the number of selected items with GetSelectedItemCount. GetCountPerPage returns the number of items that can fit vertically in the visible area of the control (in list or report view) or the total number of items in the control (icon or small icon view).

Finally, SortItems can be used to sort the items in a list control. Pass the address of a wxListCtrlCompare function that takes two item data values and a further data integer, and returns an integer representing the ordering of the two items. This integer should be zero for identity, negative if the first is less than the second, and positive if the first is greater than the second. For sorting to work, you must associate a long integer value with each item (via wxListItem::SetData, for example). These values will be passed to the comparison function.

The following fragment shows how to create and populate a report list control. The list has three columns and ten items, each with a 16×16 file icon at the start of the row.

Normally, wxListCtrl stores the label, image, and visual attributes for each item. This is fine for a modest amount of data, but if you have thousands of items, you may want to consider implementing a virtual list control. You supply the virtual functions OnGetItemLabel, OnGetItemImage, and OnGetItemAttr for the control to call when it needs the information. You must call SetItemCount to indicate how many items there are in the list control because you won’t be appending any items in the usual way. You can optionally use EVT_LIST_CACHE_HINT to update your internal structures for a given range of items, just before painting is about to happen. Here are trivial examples of the three overridden functions:

To create and populate the virtual list, we don’t append any items; we simply set the item count to a ridiculously large number:

When the underlying data changes in the control, set the item count if it has changed and call wxListCtrl::RefreshItem or wxListCtrl::RefreshItems.

For a full sample, please see samples/listctrl.

wxWizard generates wxWizardEvent events, which are described in Table 12-7. These events are sent first to the page, and if not processed, to the wizard itself. Except for EVT_WIZARD_FINISHED, event handlers can call wxWizard Event::GetPage to determine the currently active page.

These are the main member functions for wxWizard.

GetPageAreaSizer returns the sizer that manages the page area. Add all pages to this sizer, or one page from which the others can be reached with GetNext, to make the wizard size itself according to the maximum page size. If you don’t do this, you should call FitToPage for the first page before running the wizard, or for all pages if calling wxWizardPage::GetNext might not visit all pages.

GetCurrentPage returns the current active page, or NULL if RunWizard is not executing.

GetPageSize returns the size available for all pages. You can use SetPageSize to set the page size used by all pages, but this is deprecated in favor of adding pages to the sizer returned by GetPageAreaSizer.

Call RunWizard to set the wizard running, passing the first page to be shown. RunWizard returns true if the user successfully finished the wizard, or false if the user cancelled it.

To specify the border around the page area, call SetBorder. The default is zero.

Let’s examine the wxWizard sample from the wxWidgets distribution. It consists of four pages, illustrated in Figure 12-3 (the numbers are for clarity and are not on the actual dialogs).

Figure 12-3 Wizard sample

The first page is so simple that it doesn’t have its own derived class—the driving function MyFrame::OnRunWizard simply creates an instance of wxWizardPageSimple and adds a static text control to it, like this:

The second page, wxCheckboxPage, is derived from wxWizardPage and implements GetPrev and GetNext. GetPrev always returns the first page, but GetNext can return either the next page or the last page, depending on whether the user checked Skip the Next Page. Here’s the declaration and implementation of wxCheckBoxPage:

The third page, wxRadioboxPage, intercepts cancel and page changing events. If you try to cancel at this point, you will be asked to confirm the cancel: if you click on No, wxWizardEvent::Veto will be called and the wizard will not be cancelled. OnWizardPageChanging vetoes any attempt to go forwards or backwards that hasn’t first been specified using the radio buttons. In a realistic application, you might use the page changing event to ensure that the user has filled out all mandatory fields in this page before proceeding. Or you may want to prevent the user from going back one page for some reason. This is the code for wxRadioboxPage:

The fourth and last page, wxValidationPage, overrides TransferDataFromWindow to do a validation check on the state of the check box. TransferDataFromWindow is called whenever the Back or Next buttons are clicked, and if the validation or data transfer fails, the page is not changed. As with all dialogs, instead of overriding TransferDataFromWindow, you can use validators for the page controls. This page also demonstrates the use of an image for a particular page, overriding the image passed to the wizard constructor. Here’s the code for wxValidationPage:

The code that puts all the pages together and starts the wizard looks like this:

When the wizard is finished or canceled, MyFrame intercepts the events and, in this example, reports them on the frame’s status bar. You could equally intercept these events in a class derived from wxWizard.

The full listing of the sample can be found in Appendix J, “Code Listings,” and the code can be found in examples/chap12 on the CD-ROM.

Table 12-8 lists the styles you can pass to the wxHtmlWindow constructor or Create function. Also refer to the available styles for wxWindow in Table 4-1.

These are the main member functions for wxHtmlWindow.

GetInternalRepresentation returns the top-level wxHtmlContainerCell object, whose size you can query with GetWidth and GetHeight to get the overall size of the HTML.

LoadFile loads HTML from a file and displays it. LoadPage takes a location, which may be a URL. Examples of locations include:

SetPage sets the page using an HTML string rather than a file name or location.

OnCellClicked is called when there was a mouse click inside a cell. It takes a wxHtmlCell pointer, x and y coordinates, and a wxMouseEvent reference. The default behavior is to call OnLinkClicked if the cell contains a hyperlink.

OnLinkClicked takes a wxHtmlLinkInfo reference, and its default behavior is to load the linked page with LoadPage. You can override this behavior, for example to show the application’s home page in the default browser when the user clicks on the link in your “About” box.

You can also override OnOpeningURL, which is called when a URL is being opened, and OnCellMouseHover, called when the mouse moves over an HTML cell.

ReadCustomization and WriteCustomization are used to preserve fonts and borders, and they take a wxConfig* argument and optional path to use in the configuration object.

You can select text with the functions SelectAll, SelectLine, and SelectWord. SelectionToText returns a string with the plain text in the selection. ToText returns the entire page as plain text.

Call SetBorders to set the space around the HTML. SetFonts enables you to set the faces for normal and fixed fonts, and optionally you can pass an array of seven integers specifying the point sizes of the seven font sizes.

AppendToPage can be used to add HTML to the current page and refresh the window.

You can write a custom wxHtmlFilter to read special files, and you can call AddFilter to register it with wxHtmlWindow. For example, you might write a filter to decrypt an encrypted HTML e-book.

GetOpenedAnchor, GetOpenedPage, and GetOpenedPageTitle return information about the currently loaded page.

wxHtmlWindow has a history mechanism, which you can access with HistoryBack, HistoryForward, HistoryCanBack, HistoryCanForward, and HistoryClear.

You can also add windows, including your own custom controls, to an HTML page, as Figure 12-6 shows. This is done by writing a custom “tag handler,” which parses the HTML fragment for a specified tag name and creates and inserts a window.

Figure 12-6 Embedded HTML widget demo

This is part of the HTML page shown in the screenshot:

The code to implement the custom HTML tag mybind looks like this:

This technique might be useful if you wanted to create a whole user interface around wxHtmlWindow, possibly using scripts to generate the HTML and respond to input, like a web form. Another example is a registration dialog, with text controls for the user to enter his or her details and a Register button that sends the details to your organization. Or you might want to generate a report with items that can be selected and viewed in more detail by toggling a check box next to each item.

For more details of how to write your own tag handlers, see samples/ html/widget and the wxWidgets reference manual.

It’s likely that if you use wxHtmlWindow extensively within your application, you’ll want to print HTML files, too. wxWidgets provides a class to make this easy, appropriately called wxHtmlEasyPrinting. Create one instance of this class for the lifetime of your application and then call PreviewFile and PrintFile with the name of the local HTML file to print. You can also call PageSetup to show the page setup dialog, and you can retrieve the print and page setup settings using GetPrintData and GetPageSetupData. Customize the header and footer of the printout with SetHeader and SetFooter, which can contain the keywords @PAGENUM@ (the current page) and @PAGESCNT@ (the total number of pages).

This fragment from the sample in samples/html/printing demonstrates the basic principles and shows how to change the font sizes.

For examples of all the preceding wxHTML topics, see the samples under samples/html in your wxWidgets distribution.

As you have probably gathered by now, wxGrid is not really a single class—it’s a set of interacting classes. Table 12-9 clarifies what’s available and how the classes relate to each other.

Table 12-10 lists the major grid events you can catch. Note that each EVT_GRID_... macro also has a form EVT_GRID_CMD_... that takes an identifier and can be used by an ancestor of the grid to avoid the need for deriving a new class.

The following is a selection of the most significant wxGrid functions, grouped by functionality. For a complete reference, and for the members of other related classes, please refer to the reference manual.

To process events from a taskbar icon, use the event handler macros listed in Table 12-11 to direct input to member functions that take a wxTaskBarIcon Event argument. Note that not all ports are required to send these events, and so you should override CreatePopupMenu if you want to show a popup menu in reaction to a mouse click. Note also that wxTaskBarIconEvent doesn’t pass any mouse status information such as position.

The wxTaskBarIcon API is very simple. These are all the member functions for this class.

CreatePopupMenu is a virtual function that should be overridden by the derived class to return a new wxMenu when called by wxWidgets in response to a wxEVT_TASKBAR_RIGHT_DOWN event (this event is simulated on Mac OS X). wxWidgets will also delete the menu when it is dismissed.

IsIconInstalled returns true if SetIcon was successfully called.

IsOk returns true if the wxTaskBarIcon object initialized successfully.

PopupMenu shows a menu at the current position. It’s not recommended to call this directly; instead, override CreatePopupMenu and let wxWidgets show the menu for you.

RemoveIcon removes the icon previously set with SetIcon.

SetIcon sets an icon (wxIcon) and optional tooltip text. You can call this multiple times.

The following code is the class declaration for wxFontSelectorCtrl. DoGetBestSize returns a fairly arbitrary size, 200 × 40 pixels, which will be used if no minimum size is passed to the constructor.

To store the font information associated with the control, we are using a wxFontData object, as used by wxFontDialog, so that we can store a color selection along with the font.

The control’s RTTI event table macros and creation code look like this:

The call to SetBestFittingSize tells the sizer layout algorithm to use either the initial size or the “best” size returned from DoGetBestSize as the minimal control size. The control can stretch to be bigger than this size, according to the flags passed when the control is added to a sizer.

Implementing DoGetBestSize lets wxWidgets know the optimal minimal size of the control. Providing this information means that a control can be created with default size (wxDefaultSize) and it will size itself sensibly. We’ve chosen a somewhat arbitrary but reasonable size of 200 × 40 pixels, which will normally be overridden by application code. A control such as a label or button has a natural default size, but other controls don’t, such as a scrolled window with no child windows. If your control falls into this category, your DoGetBestSize can call wxWindow::DoGetBestSize, or you can omit the function altogether. You will need to rely on the application passing a non-default size to the control’s constructor or the control being sized appropriately by a parent sizer.

If your control can have child windows of arbitrary size, and you want your control to size itself according to these child windows, you can find each child’s size using GetAdjustedBestSize, and you can return a size that fits around these. For example, say we’re implementing a window that contains two child windows, arranged horizontally. We might have this implementation:

We covered the topic of creating a new event class (wxFontSelectorCtrlEvent) and event table macro (EVT_FONT_SELECTION_CHANGED) in Chapter 3. An application that uses the font selector control doesn’t have to catch this event at all because data transfer is handled separately. In a more complex control, the event class would have specific functions; we could have provided information about the font in the event class, for example, so that handlers could retrieve the selected font with wxFontSelectorCtrlEvent::GetFont.

Our control has a very simple paint event handler, centering the sample text on the control as follows:

For drawing standard elements, such as a splitter sash or a border, consider using wxNativeRenderer (please see the reference manual for more details).

Our control detects a left-click and shows a font dialog. If the user confirmed the choice, the font data is retrieved from the font dialog, and an event is sent to the control using ProcessEvent. This event can be processed by a function in a class derived from wxFontSelectorCtrl or a function in the dialog (or other window) containing the control.

This class has no keyboard handling, but you could interpret an Enter key press to do the same as left-click. You could also draw a focus rectangle to indicate that the control has the focus, using wxWindow::FindFocus to determine whether this is the focused window. You would need to intercept focus events with EVT_SET_FOCUS and EVT_KILL_FOCUS to refresh the control so that the correct focus graphic is drawn.

If you look at implementations of wxTextCtrl, for example src/msw/textctrl.cpp, you will find that standard identifiers such as wxID_COPY, wxID_PASTE, wxID_UNDO, and wxID_REDO have default command event and UI update event handlers. This means that if your application is set up to direct events to the focused control (see Chapter 20, “Perfecting Your Application”), your standard menu items and toolbar buttons will respond correctly according to the state of the control. Our example control is not complex enough to warrant these handlers, but if you implement undo/redo or clipboard operations, you should provide them. For example:

As we saw in Chapter 9, “Creating Custom Dialogs,” validators are a very convenient way to specify how data is validated and transferred between variables and associated controls. When you write a new control class, you can provide a special validator class to use with it.

wxFontSelectorValidator is a validator you can use with wxFontSelector Ctrl. You can pass font and color pointers or a pointer to a wxFontData object. These variables are usually declared in the dialog class so that they persist and can be retrieved when the dialog has been dismissed. Note that the validator is passed as an object, not using the new operator, and the object is copied by SetValidator before it goes out of scope and is deleted.

For example:

The m_font and m_fontColor variables (or m_fontData variable) will reflect any changes to the font preview made by the user. This transfer of data happens when the dialog’s TransferDataFromWindow function is called (which it is by default, from wxWidgets’ standard wxID_OK handler).

You must implement a default constructor, further constructors that take pointers to variables, and a Clone function to duplicate the object. The Validate function should be implemented to check that the data in the control is valid, showing a message and returning false if not. TransferToWindow and TransferFromWindow must be implemented to copy the data to and from the control, respectively.

Here’s the declaration of wxFontSelectorValidator:

We will leave you to peruse the source in fontctrl.cpp to find out how the class is implemented.

If your class is to be used with XRC files, it is convenient to provide a suitable resource handler to use with the control. This is not illustrated in our example, but refer to the discussion of the XRC system in Chapter 9, and refer also to the existing handlers in the directories include/wx/xrc and src/xrc in your wxWidgets distribution.

After the handler is registered by an application, XRC files containing objects with your control’s properties will be loaded just like any file containing standard wxWidgets controls. Writing the XRC file is another matter, though, because design tools cannot currently be made aware of new resource handlers. However, with DialogBlocks’ simple “custom control definition” facility, you can set up the name and properties for a custom control, and the correct XRC definition will be written, even if it can only display an approximation of the control while editing.

When writing your own control, you need to give wxWidgets a few hints about the control’s appearance. Bear in mind that wxWidgets tries to use the system colors and fonts wherever possible, but also enables an application to customize these attributes where permitted by the native platform. wxWidgets also lets the application and the control choose whether or not child windows inherit their attributes from parents. The system for controlling these attributes is a little involved, but developers won’t have to know about these unless they heavily customize control colors (which is not recommended) or implement their own controls.

If explicitly provided by an application, foreground colors and fonts for a parent window are normally inherited by its children (which may include your custom control). However, this may be overridden—if the application has called SetOwnFont for the parent, the child controls will not inherit the font, and similarly for SetOwnForegroundColour. Also, your control can specify whether it can inherit its parent’s foreground color by returning true from ShouldInheritColours (the default for wxControl, but not for wxWindow). Background colors are not explicitly inherited; preferably, your control should use the same background as the parent by not painting outside the visible part of the control.

In order to implement attribute inheritance, your control should call InheritAttributes from its constructor after window creation. Depending on platform, you can do this when you call wxControl::Create from within your constructor.

Some classes implement the static function GetClassDefaultAttributes, returning a wxVisualAttributes object with background color, foreground color, and font members. It takes a wxWindowVariant argument used only on Mac OS X. This function specifies the default attributes for objects of that class and will be used by functions such as GetBackgroundColour in the absence of specific settings provided by the application. If you don’t want the default values to be returned, you can implement it in your class. You will also need to override the virtual function GetDefaultAttributes, calling GetClassDefaultAttributes, to allow the correct attributes to be returned for a given object. If your control has similar attributes to a standard control, you could use its attributes, for example:

The wxVisualAttributes structure is defined as follows:

If your control should have a transparent background—for example, if it’s a static control such as a label—then provide the function HasTransparent Background as a hint to wxWidgets (currently on Windows only).

Finally, sometimes your control may need to delay certain operations until the final size or some other property is known. You can use idle time processing for this, as described in “Alternatives to Multithreading” in Chapter 17, “Writing Multithreaded Aplications.”

The example we looked at previously, wxFontSelectorCtrl, was simple enough that we could briefly demonstrate the basics of creating new control, event, and validator classes. However, it’s a bit thin on interesting display and input code. For a more complex example, take a look at wxThumbnailCtrl in examples/chap12/thumbnail on the CD-ROM. This control displays a scrolling page of thumbnails (little images) and can be used in any application that deals with images. (In fact, it’s not limited to images; you can define your own classes derived from wxThumbnailItem to display thumbnails for other file types, or for images within archives, for example.)

Figure 12-10 shows the control being used with a wxGenericDirCtrl inside an image selection dialog (wxThumbnailBrowserDialog). The supplied sample comes with a selection of images in the images subdirectory for demonstration purposes.

Figure 12-10 wxThumbnailCtrl used in an image selection dialog

The class illustrates the following topics, among others:

wxThumbnailCtrl doesn’t load a directory full of images itself; for flexibility, wxThumbnailItem objects are explicitly added, as the following code shows:

If you look through the source code in thumbnailctrl.h and thumbnail.cpp, you should get plenty of ideas for implementing your own controls. Feel free to use wxThumbnailCtrl in your own applications, too.