Apache OpenOffice (AOO) Bugzilla – Issue 3987
Search should include current values of fields
Last modified: 2013-02-07 22:33:36 UTC
Searches for text in documents do not return all occurences of "find" field because fields are not searched even when the document is read-only and fields cannot be highlighted.
Reassigned to Christian.
Reassiged to Bettina.
*** Issue 13683 has been marked as a duplicate of this issue. ***
This issue is just one of a related group of issues regarding the interaction between search/replace and fielding. See also #13680, #13682, #13683. In 1.0.2, fields cannot be inserted into either search or replace text, and a cut of text containing fields pastes with the expansions of the fields. In addition, a search does not match on document text containing fields even if the field expansion is identical to the searched text. This behavior is unfortunate because it precludes (for example): a) searching for all occurances of a userfield as opposed to the text that is that field's value; b) replacing with a field or text containing a field, so that if one wants to replace all occurances of "Foo" with a variable field (whose expansion might be the same for now but may be changed later) then you have to do it manually. These and many other user actions are reasonable and useful and should be supported. However, there is a design problem here. On the one hand, the user may reasonably want a search text containing a field to match only document text containing that same field. On the other hand, he may want the search to match any document text that expands to the same (fieldless) text that the search text expands to. Both are reasonable needs. Hence I propose that the search/replace dialog and semantics be changed as follows: 1) Both search and replace text should support all entry that is possible in the main document, including the insertion of field references. 2) Text cut from the main doument and pasted into either search or replace texts should preserve any embedded field references unexpanded. 3) There should be an "Expand fields?" check box next to each of the search and replaces entry boxes. If checked, search compares the expanded texts in the search entry with the expanded text of the document, and replace inserts the expanded text of the replace box. If unchecked, then search compares the unexpanded text of the entry with the unexpanded text of the document and requires an exact non-textual match for any embedded fields, while replace inserts the field reference instead of its expansion. Note that when unchecked a search text containing one uservariable field will not match a document text containing a different uservariable, even if the expansions of the two variables are the same. 4) The default search/replace menu should have the "Expand fields?" unchecked. This design supports using either expansion text or the references themselves in either search, replace, both, or neither. It does not support search or replace text that contains multiple fields only some of which are to be expanded. However, that behaviour can be synthesized by the user by typing in the expansion directly in a text that is otherwise unexpanded, or by several partial search/replaces that insert dummy anchors. Implementation should not be too difficult. It requires that the objects behind the search/replace entry boxes be changed to sections (or whatever is the object under a document that accepts fields). It also requires that comparison be either to expanded or unexpanded texts. Comparison at present seems to leave the document unexpanded, so the expanding compare may have to be coded. The dialog change is trivial.
*** Issue 38267 has been marked as a duplicate of this issue. ***
*** Issue 50270 has been marked as a duplicate of this issue. ***
"Number of words" (word count) doesn't take fields into account. OOo is not entitled to decide what is a word and what is not. So this issue should be classified as "defect".
*** Issue 52865 has been marked as a duplicate of this issue. ***
*** Issue 69596 has been marked as a duplicate of this issue. ***
Dear developers, any progress with this issue? Thanks a lot.
*** Issue 93943 has been marked as a duplicate of this issue. ***
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".
*** Issue 114042 has been marked as a duplicate of this issue. ***