Description: In the Dialog Editor, setting the "Selection" property for a Listbox control, the interface allows the users to insert twice (or more) the same item. This can happens intentionally, inserting two same indexes, or unintentionally, caused by the bug 166613. When this happens, the XML code of the dialog became invalid, because an XML element violate the attribute unicity rule, as in: <dlg:menuitem dlg:value="--something--" dlg:selected="true" dlg:selected="true"/> Then, the entire document containing the dialog cannot be saved. The saving procedure aborts, leaves a temporary file lu*.tmp and shows this message: "Error saving the document <filename>. General Error. General input/output error". Steps to Reproduce: 1. Type Ctrl+N to create a new document with Calc or Writer 2. Click the menu Tools > Macros > Organize Dialogs... 3. In the list on the left, click the new document tmporary name 4. Click the "New..." button 5. Click the "Ok" button to confirm the name of the new dialog 6. Click the name "Standard" immediately above the dialog name, then click the dialog name: the Edit button become enabled. 7. Click the Edit button: a draft of the new dialog become visibile 8. The Toolbox toolbar should be visible: else put a check on the menu View > Toolbars > Toolbox. 9. On the Toolbox click the List Box icon. 10. Put the mouse cursor over the dialog draft, then drag it diagonally. A ListBox control will be created and selected. 11. While it is selected, enlarge the Property pane to see all icons in the rows 12. In the "List entries" property, click the Multiline Editing button, write at least 2 rows (the items), then click Ok 13. In the "Selected" property, click the Multiline Editing button, write two rows containing both 1, then click Ok 14. Go to the document window. 15. Try to save the document Actual Results: 1. The interface for Selected (step 13) do not filter the duplicated input. 2. The procedure that generate XML make invalid elements. 3. The document is not saved and the error message do not tell why. 4. A new lu*.tmp file is added. Expected Results: 1. The interface automatically removes the duplicated input and shows the corrected Selection property value. (Alternatively, it could sollecitate the user to correct the problem) 2. Furthermore, for security robustness, the procedures that generate XML code checks for the attribute unicity rule, every time they add an attribute to an element. 3. If possible, the document saving procedure ignores the correctness of the dialog, saving it as is, as a draft. Checking the correctness of the dialog is up to the document loading procedure. 4. If the inner dialog is a real impediment to save the document, the application shows a message suggesting the user to correct the dialog. 5. No file *.tmp remains, also when the document can be saved Reproducible: Always User Profile Reset: No Additional Info: Tested on version 7.2.1.2, 25.2.3.2 and Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6190fe56f72008e0b6d0e502bf94099e72b9d202 CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: threaded
Thank you for reporting the bug. I followed the steps below and my results were largely similar using the versions of LibreOffice listed below. My testing did not result in an "lu*.tmp" file, and the file was saved. However, there was no error regarding the invalid dialog configuration and upon re-opening the entries in the "Selection" area had been removed. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 2; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
More information tested on version 25.2.3.2. After trying to save the document and failing, I tried to reopen the dialog (selecting it on the Macro Organizer and clicking Edit). Results. The IDE window no longer showed my dialog. The Object Catalog was not visible. The View menu no longer contained the Object Catalog item. Creating a macro module and reopening the IDE window to write the macro, the Object Catalog became visible again and declared the existence of the dialog. Clicking on Dialog1 (the name of my dialog), the IDE returned empty as in the previous results.
(In reply to Jeremy Norvell from comment #1) > Thank you for reporting the bug. I followed the steps below and my results > were largely similar using the versions of LibreOffice listed below. Thank you. Based on your comment, your results was very different, also on version 25.2.3.2 that is same as mine. If you can save the document, the bug status should be set back to UNCONFIRMED. > My testing did not result in an "lu*.tmp" file, and the file was saved. > However, there was no error regarding the invalid dialog configuration and > upon re-opening the entries in the "Selection" area had been removed. It looks like something deleted the Selection property of the Listbox *before* you tried to save. Could you please check exactly what steps you took after setting the Selection? In the test, try changing something at this final stage: it is important to check if you sometimes fail to save.
(In reply to Alfio Littletree from comment #3) > (In reply to Jeremy Norvell from comment #1) > > Thank you for reporting the bug. I followed the steps below and my results > > were largely similar using the versions of LibreOffice listed below. > > Thank you. Based on your comment, your results was very different, also on > version 25.2.3.2 that is same as mine. If you can save the document, the bug > status should be set back to UNCONFIRMED. > > > My testing did not result in an "lu*.tmp" file, and the file was saved. > > However, there was no error regarding the invalid dialog configuration and > > upon re-opening the entries in the "Selection" area had been removed. > > It looks like something deleted the Selection property of the Listbox > *before* you tried to save. Could you please check exactly what steps you > took after setting the Selection? In the test, try changing something at > this final stage: it is important to check if you sometimes fail to save. Jeremy was missing from Cc.
I can confirm the behavior described by Alfio for the following version: Version: 24.8.7.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 12; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE 24.8.7-1 Calc: CL threaded After deleting the duplicate selection in the listbox's attributes, saving is possible. The behavior is very confusing because one assumes that the dialog editor sets the attributes correctly.
Hello. I've repeated my tests in v25.3.2 on Windows 10 and I'm getting the same results that I noted before. Let me add more details so I can see if I'm differing in my approach. I am starting at your Step 12, as your instructions seem very clear up to then. 12. In the "List entries" property, click the Multiline Editing button, added two lines "Row 1", <enter>, "Row 2", then click 'OK'. The List entries field now shows "Row 1";"Row 2". 13. In the "Selection" property, click the Multiline Editing button, added two lines "Row 1", <enter>, "Row 2", then click 'OK'. The List entries field now shows "Row 1";"Row 2". As a side note, I have also tried this with new values (e.g. "Row 3", and "Row 4") with the same result. 14. Scrolling up and down in the "General" tab for the list box, I can see that both "List entries" and "selection" show the multi-value entries 15. Without closing the dialog window, I change windows to the main document (I have done this by both selecting the main document window if it overlaps or by selecting "Window"->"WhateverMyDocIsCalled.odt - LibreOffice Writer"). NOTE: Confirming Alfio's hypothesis: before I even save, I can see that the values present in "Selection" have now been cleared. 16. Trying to save via the disk icon or the "File"->"Save" both seem to work, the document is saved with no error. However, I don't see any errors or the generation of "lu*.tmp"
(In reply to Jeremy Norvell from comment #6) > 13. In the "Selection" property, click the Multiline Editing button, added > two lines "Row 1", <enter>, "Row 2", then click 'OK'. The List entries field > now shows "Row 1";"Row 2". Thank you Jeremy for your detail, they are very accurate, as I desired. The difference in your approach is in step 13. The Multiline Editing tool for the line Selection do not accept text items. It requires only numbers: more precisely, it wants indexes 0-based for counting the "List Entries". Because in your List Entries you had two text, the only admissible number for Selected are 0 or 1, without words as "Row". If you had five Entries, you could write only the numbers 0, 1, 2, 3 or 4. Because you inserted texts instead of numeric indexes, your texts was (correctly) refused. In my step 13, I inserted two valid numbers 1<enter>1 then clicked Ok.
(In reply to F. Tremmel from comment #5) > The behavior is very confusing because one assumes that the dialog editor > sets the attributes correctly. The problem is going to be solved. In version 25.8 the ellipsis tool (to the right) will works perfectly. It is most intuitive than the Multiline Editing.
I add a new detail for developers. The comment #6 by Jeremy Norvell found out also a difference between the custom ListBoxes in Writer and those in Calc. In Writer, inserting uncorrect values in Selection property, they are removed from Selection before saving. In Calc, the incorrect values are not removed, they become zeroes.