https://bugs.documentfoundation.org/show_bug.cgi?id=96896
--- Comment #14 from [email protected] --- Hi, (In reply to castanheira from comment #13) > I am actually able to edit the doc after step 4 in case 2. Surprisingly, I > am also able to edit the doc before step 3! I haven't noticed that before. > When a new doc is opened using > loadComponentFromURL("private:factory/swriter","_blank",0,OpenOptions) and > OpenOptions has a value "ReadOnly" = True, the expression "(read-only)" is > appended to the window title, but document is not put in read-only mode. It > is not possible to toggle edit mode using Ctrl+Shift+M (grayed out under > Edit menu). This behaviour is the same whether window title is changed or > not. > To further investigate the behaviour of loadComponentFromURL with the URL > "private:factory/swriter", I've removed the value "ReadOnly" from > OpenOptions. Document is opened in edit mode as expected, but Ctrl+Shift+M > is grayed out under Edit menu until you save document. > So, it seems that a document cannot be put in read-only mode before it is > saved to disk. If so, loadComponentFromURL with URL > "private:factory/swriter" and OpenOptions "ReadOnly"=True should be > considered unsupported. Nevertheless, Libreoffice appends "(read-only)" to > the window title... That is correct. Doc needs to be saved before read-only mode can be toggled. When trying to switch to read-only mode in a new doc I even get a dialog asking me to save the doc first. Perhaps a fix for this,as you also mention, would be: If a doc is opened with a factory/swriter url then read-only mode should be false only. > However, when an existing document is opened using > loadComponentFromURL("file:///C:/Users/Public/existing.odt","_blank",0, > OpenOptions) and OpenOptions has a value "ReadOnly" = True, the expression > "(read-only)" is appended to the window title and, as expected, document > actually opens in read-only mode. Then, if window title is changed using API > and print preview is selected, the expression "(read-only)" dissapears but > document remains in read-only mode. Thanks for confirming this. I was expecting this only as, you would agree with me, title change will not effect the actual mode of the document. This then is the problem related to the m_bExternalTitle parameter for the impl_updateTitleForModel function. >Wow =) I just love the analysis from you guys; TBH at this point - I suspect >>that no-one else in the project has as deep an understanding of you guys of >>this code as is shown in the analysis here. :) > Can any dev help me on this? >git grep -10 leaseNumber >shows a number of comphelper/ hits - I guess the lease is expired and then >>re-used or somesuch (but having not read it - I have far less insight than >you >as to what is going on ) - it strikes me Stephan may have a view on >framework/ >pieces though. Thanks for pointing this out.I have figured it out =). In comphelper/source/misc/numberedcollection.cxx the leaseFunction maintains a hash with component(a weak reference to it) and its leaseNumber. Now this component reference doesn't match with the reference of the controller passed to the impl_updateTitleForController method. Because a weak reference is being obtained to the original controller and being passed as the component reference. Hence, even when the original controller is disposed, the hash table entry is not deleted as it is maintaining a reference to a reference. It only gets deleted later. Hence the number changes between 2 and 3. >In terms of proceeding; what I would suggest is: >a) fix the bug how you think best (akash) At this moment I am pretty sure on how the bug has to be solved. In my gdb session I am able to recreate the release of the number by a controller and the title behaves the way in the way it should. But I am facing a issue: 1. A frame detach event, obviously, has a frame as the source. It is possible to get the controller related to the frame as well. When the frame event occurs, we have no data related to the controller. And if we try to get the data of the controller, we lose information about the type of the event that has caused us to get the data. Data such as numbered collection is also needed in all other cases. So there is no way to distinguish between the two. 2. When a new component is being set in the frame, the old controller is disposed via dispose(). Then perhaps we could call a function in this function to dispose the title. But the problem is that the controller class stores its attributes in a XTitle reference for title related things. And within the XTitle class there are only two function to get the string and to set it. Nothing else. And we need to get the numbered collection and the component reference. Then we need to obtain a weak reference to the component. 3. Then I propose to edit the XTitle class. Either to add a new function. Or to modify the setTitle function which takes a parameter bool dispose false by default but can be set to true to dispose the string.I seek your advice on this method. 4. There is another method which I explored. When a frame disposes it sends a event to its listeners. The titleHelper is one of this listener and hence recieves this event and disposes the frames lease number. Similarly when a controller disposes it also generates a event. But I was unable to find and function which would register to controller Events. If there was such a function then the title dispose would take place by itself. I saw that SfxClipboard receives controller dispose events. But was not able to find how it registered. Perhaps I will take a second look... >b) write unit tests for the document title in each of these corner-case >circumstances we've found - which will help capture your experience here for >the benefit of future fixers. >c) - lets just get that committed ... I am also eager to commit :). I just want to make sure that my testing is thorough so the application is more robust. >d) if possible make this far less recursive (ie. faster & cleaner ;-) I think there will be recursion due to the method in which a title is created. It just makes debugging difficult and tedious. Maybe after patching the bug, I will see how the process can be improved. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
