X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/77a1771911ed222ba6861ead327c3735fc16a0b1..242019eef3fdcdb12b5310da67af3ef6d15e0f58:/docs/latex/wx/wxmsw.tex?ds=sidebyside

diff --git a/docs/latex/wx/wxmsw.tex b/docs/latex/wx/wxmsw.tex
index 5e8d60ee84..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
@@ -352,7 +385,7 @@ doesn't do a perfect job of converting the project files from eVC++ format.
 
 When you have converted the wxWidgets workspace, edit the configuration properties
 for each configuration and in the Librarian, add a relative path ..$\backslash$..$\backslash$lib to
-each library path. For example: {\tt ..$\backslash$\$(PlatformName)$\backslash$\$(ConfigurationName)$\backslash$wx_mono.lib}.
+each library path. For example: {\tt ..$\backslash$\$(PlatformName)$\backslash$\$(ConfigurationName)$\backslash$wx\_mono.lib}.
 
 Then, for a sample you want to compile, edit the configuration properties
 and make sure {\tt ..$\backslash$..$\backslash$lib$\backslash$\$(PlatformName)$\backslash$\$(ConfigurationName)} is in the Linker/General/Additional
@@ -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}
+
