source/text/simpress/02/11080000.xhp


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<?xml version="1.0" encoding="UTF-8"?>


<!--***********************************************************************
 *
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 * 
 * Copyright 2000, 2010 Oracle and/or its affiliates.
 *
 * OpenOffice.org - a multi-platform office productivity suite
 *
 * This file is part of OpenOffice.org.
 *
 * OpenOffice.org is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Lesser General Public License version 3
 * only, as published by the Free Software Foundation.
 *
 * OpenOffice.org is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Lesser General Public License version 3 for more details
 * (a copy is included in the LICENSE file that accompanied this code).
 *
 * You should have received a copy of the GNU Lesser General Public License
 * version 3 along with OpenOffice.org.  If not, see
 * <http://www.openoffice.org/license.html>
 * for a copy of the LGPLv3 License.
 *
 ************************************************************************--><helpdocument version="1.0">
<meta>
<topic id="textsimpress0211080000xml" indexer="include" status="PUBLISH">
<title xml-lang="en-US" id="tit">Hide Subpoints  </title>
<filename>/text/simpress/02/11080000.xhp</filename>
</topic>
<history>
<created date="2003-10-31T00:00:00">Sun Microsystems, Inc.</created>
<lastedited date="2003-10-31T00:00:00">converted from old format - fpe</lastedited>
</history>
</meta>
<body>
  
  
  <section id="unterversteck">
  <bookmark branch="index" xml-lang="en-US" id="bm_id3146119"><bookmark_value>subpoints; hiding</bookmark_value><bookmark_value>hiding; subpoints</bookmark_value></bookmark><bookmark xml-lang="en-US" branch="hid/.uno:OutlineCollapse" id="bm_id3444362" localize="false"/><!-- HID added by script -->
<bookmark branch="hid/.uno:OutlineCollapse" xml-lang="en-US" id="bm_id3154014"/><paragraph l10n="U" role="heading" level="1" id="hd_id3146119" oldref="1" xml-lang="en-US"><link href="text/simpress/02/11080000.xhp" name="Hide Subpoints">Hide Subpoints</link>  </paragraph>
  <paragraph l10n="U" role="paragraph" id="par_id3154490" xml-lang="en-US" oldref="2"><ahelp visibility="visible" hid=".uno:OutlineCollapse">Hides the subheadings of a selected heading. Hidden subheadings are indicated by a black line in front of a heading. To show the lower level headings, click the <link href="text/simpress/02/11090000.xhp" name="Show Subpoints"><emph>Show Subpoints</emph></link> icon.</ahelp></paragraph>
  </section>
  <section id="syunterversteck">
  <table id="tbl_id3153714">
   
   
    <tablerow>
     <tablecell>
      <paragraph l10n="E" role="paragraph" id="par_id3155961" xml-lang="en-US" oldref=""><image src="cmd/sc_outlinecollapse.png" id="img_id3149256"><alt xml-lang="en-US" id="alt_id3149256">Icon</alt></image></paragraph>
     </tablecell>
     <tablecell>
      <paragraph role="paragraph" id="par_id3148489" l10n="U" xml-lang="en-US" oldref="3">Hide Subpoints</paragraph>
     </tablecell>
    </tablerow>
   
  </table>
  </section>
  
 </body>
</helpdocument>
Age	Commit message (Collapse)	Author
2024-06-26	Missing includes	Stephan Bergmann
	Change-Id: I519cdb9b5a1c475a1d36293b77c85c250baf3c3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169520 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-06-05	Adapt compilerplugins to Clang 17 trunk "Remove llvm::Optional"	Stephan Bergmann
	(<https://github.com/llvm/llvm-project/commit/397f2e9ebee8d8e45547e90dd05228d7f965df67>) Change-Id: I51acda5951f8250d1a1b47e1c2612199ae7338a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152618 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-30	Missing include for llvm::Optional	Stephan Bergmann
	...with recent Clang 17 trunk after <https://github.com/llvm/llvm-project/commit/125f4457a54a550846732763ee36b1447ec8d66e> "[clang] Remove clang::Optional" Change-Id: If33406604a614a65dd17e269a0a5c167ea263328 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146347 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-17	Bump compiler plugins Clang baseline to 12.0.1	Stephan Bergmann
	...as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html> "Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html> "Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up compilerplugins/clang/ accordingly Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-23	Don't call isIntegerConstantExpr on value dependent Expr	Stephan Bergmann
	...as it causes Clang to fail with > Assertion failed: (!isValueDependent() && "Expression evaluator can't be called on a dependent expression."), function isIntegerConstantExpr, file .../llvm/llvm-project/clang/lib/AST/ExprConstant.cpp, line 15487. Change-Id: I335f7610955c30a5c102bfb3b8aa6441a30dd247 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108241 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-28	Extend loplugin:elidestringvar to OString	Stephan Bergmann
	(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar] > aXmlWriter.content(sPdfConformance); > ^~~~~~~~~~~~~~~ > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar] > OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B"; > ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ) Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16	Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString	Stephan Bergmann
	...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-29	Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually used	Stephan Bergmann
	0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator == overloads, but they never got called because the existing 'sal_Unicode const ' overloads always won. (The other function overloads introduced with 0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not have any 'sal_Unicode const ' overload counterparts.) Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant fallout. For one, those plugins look at the actual ctor overloads being used, so had missed those cases that accidentally had used an unexpected overload. And for another, the heuristic the plugins used to detect the ConstCharArrayDetector overloads turned out to be too simplistic now and would have started to cause false positives. Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>