- scrolling area. This is now the default when you set an interior sizer
- into a wxScrolledWindow with wxWindow::SetSizer.
- The scrolling area will be set to the size requested by the sizer and
- the scrollbars will be assigned for each orientation according to the need
- for them and the scrolling increment set by
- wxScrolledWindow::SetScrollRate.
- As above, scrolling is only enabled in orientations with a non-zero
- increment. You can influence the minimum size of the scrolled area
- controlled by a sizer by calling
- wxWindow::SetVirtualSizeHints.
- (calling wxScrolledWindow::SetScrollbars
- has analogous effects in wxWidgets 2.4 -- in later versions it may not continue
- to override the sizer)
-
- Note: if Maximum size hints are still supported by SetVirtualSizeHints, use
- them at your own dire risk. They may or may not have been removed for 2.4,
- but it really only makes sense to set minimum size hints here. We should
- probably replace SetVirtualSizeHints with SetMinVirtualSize or similar
- and remove it entirely in future.
-
- As with all windows, an application can draw onto a wxScrolledWindow using
- a @ref overview_dcoverview "device context".
-
- You have the option of handling the OnPaint handler
- or overriding the wxScrolledWindow::OnDraw function, which is
- passed a pre-scrolled device context (prepared by
- wxScrolledWindow::DoPrepareDC).
-
- If you don't wish to calculate your own scrolling, you must call DoPrepareDC
- when not drawing from
- within OnDraw, to set the device origin for the device context according to the
- current
- scroll position.
-
- A wxScrolledWindow will normally scroll itself and therefore its child windows
- as well. It
- might however be desired to scroll a different window than itself: e.g. when
- designing a
- spreadsheet, you will normally only have to scroll the (usually white) cell
- area, whereas the
- (usually grey) label area will scroll very differently. For this special
- purpose, you can
- call wxScrolledWindow::SetTargetWindow which means that pressing
- the scrollbars will scroll a different window.
-
- Note that the underlying system knows nothing about scrolling coordinates, so
- that all system
- functions (mouse events, expose events, refresh calls etc) as well as the
- position of subwindows
- are relative to the "physical" origin of the scrolled window. If the user
- insert a child window at
+ scrolling area. This is now the default when you set an interior sizer into
+ a wxScrolled with wxWindow::SetSizer(). The scrolling area will be
+ set to the size requested by the sizer and the scrollbars will be assigned
+ for each orientation according to the need for them and the scrolling
+ increment set by SetScrollRate(). As above, scrolling is only enabled in
+ orientations with a non-zero increment. You can influence the minimum size
+ of the scrolled area controlled by a sizer by calling
+ wxWindow::SetVirtualSizeHints(). (Calling SetScrollbars() has analogous
+ effects in wxWidgets 2.4 -- in later versions it may not continue to
+ override the sizer.)
+
+ Note that if maximum size hints are still supported by
+ wxWindow::SetVirtualSizeHints(), use them at your own dire risk. They may
+ or may not have been removed for 2.4, but it really only makes sense to set
+ minimum size hints here. We should probably replace
+ wxWindow::SetVirtualSizeHints() with wxWindow::SetMinVirtualSize() or
+ similar and remove it entirely in future.
+
+ As with all windows, an application can draw onto a wxScrolled using a
+ @ref overview_dc "device context".
+
+ You have the option of handling the OnPaint handler or overriding the
+ wxScrolled::OnDraw() function, which is passed a pre-scrolled device
+ context (prepared by wxScrolled::DoPrepareDC()).
+
+ If you don't wish to calculate your own scrolling, you must call
+ DoPrepareDC() when not drawing from within OnDraw(), to set the device
+ origin for the device context according to the current scroll position.
+
+ A wxScrolled will normally scroll itself and therefore its child windows
+ as well. It might however be desired to scroll a different window than
+ itself: e.g. when designing a spreadsheet, you will normally only have to
+ scroll the (usually white) cell area, whereas the (usually grey) label area
+ will scroll very differently. For this special purpose, you can call
+ SetTargetWindow() which means that pressing the scrollbars will scroll a
+ different window.
+
+ Note that the underlying system knows nothing about scrolling coordinates,
+ so that all system functions (mouse events, expose events, refresh calls
+ etc) as well as the position of subwindows are relative to the "physical"
+ origin of the scrolled window. If the user insert a child window at