Description: Marking/overwriting part of a cross reference leads to different beahaviors depending on whether the reference has been edited before since the document was opened. Ref 1 has a leading space included in the ref source Ref 2 has no spaces Ref 3 has a space following the text included in the source Steps to Reproduce: 1st scenario: 1.Open attached file (or create new file --> type a word --> set reference [Insert - Field - More Fields - Cross-references]) 2. doubble click on first Ref* to mark the word 3. type new word 2nd scenario: 1. open document 2. klick inside Ref* and delete a character or add one 3. double click to markt the word 4. type to replace with new word 3rd scenario: 1. open document 2. put cursor at the end of one of the Ref* 3. use backspace to delete the word 4. Type new word Actual Results: 1st scenario: (see attachment [Refs double click no edit]) - Ref1 --> first letter of the new word gets included into the cross ref; the rest doesn't - Ref2 --> cross ref get destroyed - Ref3 --> none of the new characters get included into the cross ref 2nd scenario: (see attachment [Refs with editing]) - Ref1 --> new word completely in cross ref (desired behavior!!) - Ref2 --> cross ref annihilated - Ref3 --> none of the new characters get included into the cross ref 3rd scenario:(see attachment[Refs backspace no edit]) -Ref1 --> none of the newly typed characters get included in the cross ref (only leading space persists) - Ref2 --> cross ref destroyed (expected behavior!!) - Ref3 --> none of the new characters get included into the cross ref Expected Results: When double clicking a referenced word (no matter if it has a leadind/following or no space) and retyping should always keep the reference alive and replace it with the new word (see Ref1 in 2nd scenario). In my opinion the same should apply for deleting part of a referenced section (section deleted is at the end or beginning of the marked section--> deleting things in the middle doesn't cause problems) Only exception is deleting the whole referenced section/word (like Ref2 in 3rd scenario) Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.1.2 (x64) Build-ID: 4d224e95b98b138af42a64d84056446d09082932 CPU-Threads: 2; BS: Windows 10.0 Build 18362; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Created attachment 158811 [details] Test file
Created attachment 158812 [details] Scenario 3
Created attachment 158813 [details] Scenario 1
Created attachment 158814 [details] Scenario 2
I can confirm all observations with Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: CL => NEW But I'm not sure, what the expected behaviour should be. Let's ask Design-Team for further input here.
Modifying cross-references is supposed to be done per Edit > Fields dialog, see [1]. Fields are variables and I don't see need for direct editing and would block it. Unfortunately Edit > Field is disabled for some reason. Any idea, Cor? [1] https://help.libreoffice.org/6.4/en-US/text/swriter/guide/references_modify.html
(In reply to Heiko Tietze from comment #6) > Modifying cross-references is supposed to be done per Edit > Fields dialog, > see [1]. Fields are variables and I don't see need for direct editing and > would block it. Unfortunately Edit > Field is disabled for some reason. Any > idea, Cor? > > [1] > https://help.libreoffice.org/6.4/en-US/text/swriter/guide/references_modify. > html I think you misunderstood my intention. I didn't wanna edit the fields inserted based on the cross reference. What I wanted to do is edit the original referenced text, so that it changes all the fields based on it. What edit fields does, is that it lets you change an inserted field (text based on reference for example). It works but only is enable if you click in front of the field (not the original text that is referenced)
Interesting one :) So is my conclusion right, that as soon as the selection touches the limit of the defined reference field, that the reference is not extended if the text is changed? I'm tempted to suggest to look at how it works with text that has formatting as bold, italic. I would expect the same behavior in this case.
Mike, can you shed some light on this issue?
(In reply to Heiko Tietze from comment #9) No I can't; looks erratic.
Erratic behavior is a bug. Cannot help from UX POV unless to support the expectation.