after a security VS2008SP1 had known problems that are extensively
documented in Microsoft's KB971092, KB974479, KB974223 and the blog post
http://blogs.msdn.com/b/windowssdk/archive/2009/08/07/installing-windows-sdk-for-server-2008-v6-1-after-vs2008-sp1-causes-conflicts-with-security-update-kb971092.aspx

The workaround is only needed for insufficiently patched development environments.
This case should not assumed to be normal, so the workaround is now disabled by default.

From a binary perspective the wrappers allow dropping stlport4 itself
immediately and replacing it by standard compliant system or compiler
standard template libraries.

From a source code perspective the other parts of the codebase
can remain untouched for now. They can be gradually converted
from stlport4 to the TR1 or C++11 standard at a comfortable pace
later. The header wrappers will assist this source-code conversion.

Now that all packages have the same base name, the package name has
no version number at all, and there is no more basis packages, the
basis package name colides with the brand package name, for example:

ooobasis3.4-writer is now openoffice-writer
openoffice.org3-writer must be openoffice-brand-writer or the like

a standard compliant STL does NOT have these obsoleted STL headers

122096: - <OutlinerView::ToggleBullets()> - apply default bullet numbering rule on toggle on, if the current numbering r

ule is not a bullet numbering rule.
- improve application default bullet numbering rule by add corresponding spacing to the first list level
- refactoring of code introduced for paragraph property panel to handle toggle and set of bullets and numbering

Parantheses are mandatory for the print statement
since PEP-3105 (http://www.python.org/dev/peps/pep-3105/)

Patch by: Tsutomu Uchino

Found by: Tsutomu Uchino

This class is dereived from svt::PopupWindowController, derived in turn
from svt::ToolboxController, the base class of all
css.frame.ToolbarController's. Adapt getSupportedServiceNames() and the
passive component registration to reflect that fact.

It actually does not override any method in svt::StatusbarController, so
there is no point in keeping it.

in some build environments the use of std::transform() with plain pointers as
input iterators results in many warnings about how unsafe such a construct is.
The warnings could be suppressed e.g. on MSVC with the SCL_SECURE_NO_WARNINGS
define. Open coding the construct makes it cleaner and more debugable though.