X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/d6f2fae8e61d2a268e6f2c57d2905f219faf7c37..de414223ab83187113388a167dc5fa391cc9e166:/docs/latex/wx/wxmsw.tex diff --git a/docs/latex/wx/wxmsw.tex b/docs/latex/wx/wxmsw.tex index e01af3ad6e..7ed271eb6f 100644 --- a/docs/latex/wx/wxmsw.tex +++ b/docs/latex/wx/wxmsw.tex @@ -24,6 +24,39 @@ MinGW32 tool chain. For further information, please see the files in docs/msw in the distribution. +\subsection{Themed borders on Windows}\label{wxmswthemedborders} + +Starting with wxWidgets 2.8.5, you can specify the wxBORDER\_THEME style to have wxWidgets +use a themed border. Using the default XP theme, this is a thin 1-pixel blue border, +with an extra 1-pixel border in the window client background colour (usually white) to +separate the client area's scrollbars from the border. + +If you don't specify a border style for a wxTextCtrl in rich edit mode, wxWidgets now gives +the control themed borders automatically, where previously they would take the Windows 95-style +sunken border. Other native controls such as wxTextCtrl in non-rich edit mode, and wxComboBox, +already paint themed borders where appropriate. To use themed borders on other windows, such +as wxPanel, pass the wxBORDER\_THEME style, or (apart from wxPanel) pass no border style. + +In general, specifying wxBORDER\_THEME will cause a border of some kind to be used, chosen by the platform +and control class. To leave the border decision entirely to wxWidgets, pass wxBORDER\_DEFAULT. +This is not to be confused with specifying wxBORDER\_NONE, which says that there should +definitely be {\it no} border. + +\wxheading{More detail on border implementation} + +The way that wxMSW decides whether to apply a themed border is as follows. +The theming code calls wxWindow::GetBorder() to obtain a border. If no border style has been +passed to the window constructor, GetBorder() calls GetDefaultBorder() for this window. +If wxBORDER\_THEME was passed to the window constructor, GetBorder() calls GetDefaultBorderForControl(). + +The implementation of wxWindow::GetDefaultBorder() on wxMSW calls wxWindow::CanApplyThemeBorder() +which is a virtual function that tells wxWidgets whether a control can have a theme +applied explicitly (some native controls already paint a theme in which case we should not +apply it ourselves). Note that wxPanel is an exception to this rule because in many cases +we wish to create a window with no border (for example, notebook pages). So wxPanel +overrides GetDefaultBorder() in order to call the generic wxWindowBase::GetDefaultBorder(), +returning wxBORDER\_NONE. + \subsection{wxWinCE}\label{wxwince} wxWinCE is the name given to wxMSW when compiled on Windows CE devices; @@ -267,7 +300,7 @@ tooltips are distinct controls, and it will be hard to add dynamic tooltip support. Control borders on PocketPC and Smartphone should normally be specified with -wxSIMPLE\_BORDER instead of wxSUNKEN\_BORDER. Controls will usually adapt +wxBORDER\_SIMPLE instead of wxBORDER\_SUNKEN. Controls will usually adapt appropriately by virtue of their GetDefaultBorder() function, but if you wish to specify a style explicitly you can use wxDEFAULT\_CONTROL\_BORDER which will give a simple border on PocketPC and Smartphone, and the sunken border on @@ -420,3 +453,4 @@ between desktop and mobile applications, in particular for sizer layout. should be catered for, either by hard-wiring the capability into all dialogs and panels, or by providing a standard component and sizer. \end{itemize} +