Created attachment 67834 [details] File with example content, for reproducing the bug Hi To reproduce do the following steps with the attached file: 1. Select the grey box 2. Try to select the "Example Text" with one click (this doesn't work) 3. Select the "Example Text" with two clicks -> starts edit text mode instead of "normal" selection In my opinion the selection should already work with the first click. The text should get select but not in a "edit-text" mode. If you don't have the grey box selected (e.g. select the "A"-box first, the selection of the "Example Text" works as expected: 1. Select the "A"-Box 2. Select "Example Text" by clicking once at it I'm not sure if this is a bug or if you want it this way, but for me it's not a normal behavior (not as expected by average user). I want to use LibreOffice Draw for my fathers company. If you fix this till 31. October 2012 I will spend 100$ to LibreOffice. Thanks!
Comment on attachment 67834 [details] File with example content, for reproducing the bug correct mime type
The report is a little imprecise, but I think reporter wanted to say: 1. Click into the bottom right quarter of the blue rectangle (or on the grey border of the rectangle) > Rectangle becomes selected, 8 control points appear 2. do a single click on the characters of the text. Expected: Text box containing text "fsdfsfssfsfsfsdf" becomes selected Actual: selection does not change That's a very old (I see it already in OOo 1.1.5) and more general problem. As you can see with newsample.ods, If the filled background shape is selected any object in front of that background shape only can be selected by double click, a single click will not work (for yellow borders smiley, for example) Strange, you also can't select red borders smiley (with single click) as long as background rectangle is selected and if you click on the smiley inside the background rectangle area. Single click selection will work when you click red smiley shape outside background rectangle (below mouth, for example). Same problem for simple line. Problem does not exist for background object without area filling To me this behavior seems confusing and inconsistent. @Lucas Betschart: Thank you for your attention! @Lennard: You fixed "Bug 35079 - EDITING: Drawing element completely in mouse selection frame not selected", may be the insights you got there can be useful for a fix here? Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turff
Created attachment 67868 [details] New Sample Document
Well, I can just GUESS that clicking on the selected Item is processed before anything else on single-click, and if the program realizes that the selected object was hit nothing else is processed - putting the selected object back into the correct order instead of preferred processing POSSIBLY would mean that if one of the 8 control points, or some curve points would be clicked (in order to move it), they could be shadowed by objects above them so you would be stymied. Maybe clicks onto the main body could be processed by splitting the "modify-selected routine" I will try to find it, but cant say anything safe before. By the way, the NEWER attachment cannot be opened with L.O. 3.5.4.2, WIN32, XP!!! greets
Created attachment 67936 [details] New Sample Document 2 Thx that you try, that's the first real progress for this bug within 10 years :-) We are not in a hurry. > By the way, the NEWER attachment cannot be opened with L.O. 3.5.4.2, WIN32, > XP!!! Works fine with the original document on my PC, but none of my Versions I tried is able to open downloaded attachment. It seems that that document is damaged. I replaced it, hope that it now will work.
No way, the new document will not work, either. On my PC the working example is shown with 11805 bytes, the documents I uploaded and again downloaded from Bugzilla have 11686 bytes. For me this here works hope you can download sample from here: <http://www.bielefeldundbuss.de/LibO/55430/newsample.odg>
Bump I'm sorry. I would still donate the 100$, to the document foundation, to the developer or to some other organization, what ever the person who fixed it wants. Requirement is a fix for this year.
Thanks for trusting us... My current approach is to use the moment where the mouse button is RELEASED sd -> fusel.cxx -> 00641 sal_Bool FuSelection::MouseButtonUp(const MouseEvent& rMEvt) and the object has not been shifted. (Ordinarily, the control boxes change from >>scale<< to >>rotate<< then. Before this is done, I am doing a check which checks if there is an object in front of the selected one which would be clicked. But somehow it doesn't work... it seems to recognize the covering object but the following select routine fails (used mpView->BegMacroObj) Can someone tell me what MACRO-Object means in the sense of SDRSEARCH_PICKMACRO or mpView->BegMacroObj??? best regards, I hope I will fix it THIS weekend. regressions I am afraid of (if you totally remove the selected object's priority) (however avoided by my method:) 1. covered control boxes would not work anymore 2. You could not draw another object out behind another object by which it is totally covered.
Created attachment 69105 [details] Sample Document I attached a sample document what can be opened, I dentical to th one linked in <https://bugs.freedesktop.org/show_bug.cgi?id=55430#c6>
I think I have solved it. https://gerrit.libreoffice.org/927 greets Lennard
Yay thanks, cool! Write me an email (lucasbetschart@gmail.com) where I should donate the money. Will this patch land in 3.6.4?
It seems the fix hasn't been integrated into Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: 1219bc)]" {tinderbox: @16, pull time 2012-11-01 23:27:25} on German WIN7 Home Premium (64bit) yet?
Then, would you be so kind to?
(In reply to comment #13) I have no permissions and no skills for that, so I asked for Help on <libreoffice@lists.freedesktop.org>
Lennard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=85ea03ae536831649b104694d08dced4d4c8663f fdo#55430 allow clicking objects in front of selected ones The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Lennard, sorry about the delay.
(In reply to comment #11) > Yay thanks, cool! > > Write me an email (lucasbetschart@gmail.com) where I should donate the money. > > Will this patch land in 3.6.4? it depends if you wanna donate money to the organization or to the hacker who did the fix. anyway, instructions for donations to THE DOCUMENT FOUNDATION are here: http://donate.libreoffice.org/
Thanks for the hint, but I've already got a email from Lennard and donated the money to the Document Foundation. I will test the fix in the daily build as soon as possible.
OT: Is there no daily build of LO 5.7 for Debian / Ubuntu or Windows? All I see is language- and helppackages. What hardware is needed to setup a Tinderbox for an Ubuntu 12.04 x64 build? I may can organize one, if there is really no .deb available.
*3*.7, i pray? You know, you don't need tinderbox to build the stuff. http://wiki.documentfoundation.org/Development/Native_Build gives info how to build on linux. (also on windows, but I didn't try) Hint: some files are downloaded after entering make , so be sure that you start building as soon you pulled the git archive. Another issue is that you may first have to 1. Update your distro to the maximum extent 2. Then enter the corresponding deb-src lines for all deb lines in your sources.list 3. make apt-get re-read the sources list (forgot the command, but reboot will do) :( 4. AFTER that, enter apt-get update 5. AFTER that, pull the build-dependencies using sudo apt-get build-dep libreoffice HDD consumption: up to 10 GB! processors: 4 recommended, be sure that you set the compile flags to really use them! (Explained on the same page). Getting the next version: you may need to refresh your system as outlined above. git pull -r seems to break your archive sometimes, i am afraid it happens that you have to download the next version completely into a blank directory. (Happened to me at least, must have something to do with the side repositories or Michael Meeks reorganizing the module system to ,,tail-build'')
> git pull -r seems to break your archive sometimes, i am afraid it happens > that you have to download the next version completely into a blank directory. That is absolutely not true. The only catch is that, if you have some of the extra repos (binfilter, dictionaries, help, translation), you _must_ run git submodule update after git pull, or they might get out of sync. See http://wiki.documentfoundation.org/Development/Submodules for details. > (Happened to me at least, must have something to do with the side > repositories or Michael Meeks reorganizing the module system to > ,,tail-build'') tail_build is only a logical concept used by gbuild to allow building stuff from more modules together. It has nothing to do with the physical structure of the modules.
Ok, I've downloaded the source and complied, the bug not fully fixed. The basic scenario is fixed, (change focus to inner object), but this case still doesn't work: 1. Double click on the outer object to change into Textedit mode. 2. Try to select the inner object <- doesn't work I think this problem is because of another (related) bug, I just recognized: 1. Double click on the outer object to change into Textedit mode. 2. Single click on the outer object again <<- The mode is still "Textedit" and not "Select" like one would expect. You still can't select the inner object. The mode changes form "Textedit" to "Select" when you click on some free space in the page. I can't open the attached Sample Document by Rainer Bielefeld. If my description is not clear to you I will upload some screenshots.
Damn, you' re right. First of all, the new bug you described is also right! I will try to fix it. Second: There is a philosophical problem. We wont make that you can click-select an object which is in front of a totally-bigger Text you are currently editing, because this would prevent a user from repositioning the text cursor when editing text that is totally covered by another (semi-transparent) object. But of course, if it is just the shape containing the text (as in your sample), this shoulde be able with ONE click. Third: The two samples (attachment 67834 [details], attachment 69105 [details]) are s o m e h o w defective. When you edit the text in the outer object and press escape or click on the side, the object becomes invisible. Even if I make a rectangle with text in front of it and save it and load it, this happens too! And with a fresh document sample document I made with the latest Version of Lo, you are still in text mode after clicking once more but the object doesn't dissappear. But you still need TWO clicks. And then you are in rotate/shear mode. Well, I have to file these two bugs. Then I fix the still-in-text-mode-stuff first. I didn't know that custom shapes were so defective when I started spending my free time here some months ago, but thats why i am here. These experiments are only valid for writeable documents. Dont try that stuff by directly opening these attachments
Lennard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6fbba11da54b52554941f00b07e42cc5d7a1643c fdo#55430 click object in front of current after editing text The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello, It has been some time since my last check. I've now downloaded the 4.0 beta and tested it again. I don't know what you have changed with the second patch but this is still valid: 1. Double click on the outer object to change into Textedit mode. 2. Single click on the outer object again <<- The mode is still "Textedit" and not "Select" like one would expect. You still can't select the inner object. The mode changes form "Textedit" to "Select" when you click on some free space in the page. I've made a screenshot after this two steps: http://www.pic-upload.de/view-17259217/1.png.html As you can see the toolbar is still in Textedit mode (you can change the font etc.), but the selection looks like "Select"-Mode. Thanks for your work.
Which inner Object? if it is the text in the middle, you may happen to click the outer object in the place where ITS OWN text is edited. then you change the cursor of the text, and that cannot be processed as clicking the inner object, otherwise one would not be able to edit text of a selected, COVERED object anymore just by one click, which would be a regression. I Will check my other patch this evening (As well as in beta as also in the master), but beware that the patch transfer to 4.0 beta may still be incomplete. (I don't know when it will be completed). Please send your test file to Wasserthal@nefkom.net. Screenshots dont help me. The second patch I did: trapping useless clicks even during text editing and interpret them as clicking the upper object. In the case of emergency, I may better try to fix the other harmless bug you may have recognized (that you truely exit text editing after clicking out of text), but that will not make a difference.
damn it! Some other change prevents now the transfer of the single-click signal to the text routine. Thus, only the first patch works. (Both patches are found included in the 4.0 beta source, so this cant be the problem) Some crash-error during had shown up after my second patch It was fixed but obviously not intentionally- So there were at least two changes which I dont know about that had influenced these reaction chains. Too bad. We will not be able to include this until 4.1, because 4.0 doesnt take up any new patches. (Except if the fix consists in the total removal of a patch, then the function will be included in 4.0). You will have to download the 4.0 source and add the patch and compile on your own. (should be no problem on linux distros but I never tried it for Windows executables.) I hope I find the error as soon as possible.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e80a8b6f14fac6bb6cc7ea55b118f95472d5b654 fdo#55430 switches off text mode when clicking an other object. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm sorry but I had to revert the calc part of the last patch. I'll look into it as soon as possible. It was the cause for Bug 61165 which prevents all work on comments and made it impossible for me to fix a regression.
(In reply to comment #29) > [...] It was the cause for Bug 61165 ... For the record, you mean bug 61025 ??
(In reply to comment #30) > (In reply to comment #29) > > > [...] It was the cause for Bug 61165 ... > > For the record, you mean bug 61025 ?? To some part. I was working on 61165 and had to fix 61025 anyway. So yes I think I screwed up in the sentence.
So now to the patch. @Lennard: What did you try to fix with your second patch? I looked now into it with some time and there are some errors in the patch. But currently I have no idea what you tried to fix. Could you maybe add a detailed step by step instruction for me how to reproduce the problem?
First of all, the patch you partly reverted is my THIRD patch to this bug. This Patch does: * Allow you to re-select a custom shape IN CALC when you are editing text by clicking that object outside the text field. * Allows you to select an other custom shape when you are editing text by clicking that object outside the former text field even if the point where you are clicking is still inside the non-text area of that old object * Causes the programs DRAW and IMPRESS to stop thinking it is still in text mode after you select an other custom shape when you are editing text by clicking that object outside the former text field. The earlier, SECOND patch was intended for draw and impress to cause that, while text is being edited on an object, to click-select another object in front of that object. Hence, I had to insert my first stuff (contained in the ordinary clicking routines) also into the text routines, It worked only for impress because it relied on the toggle between rotation mode which is impossible in draw, so its working only in impress. (I hadn't touched calc and writer then) What of both patches do you mean with the one with errors? the second one? I knew that the 2nd was defective (for draw) so I wrote the third. And I realized that you wrote in your patch ,, this reverts e80a8b6f14fac6bb6cc7ea55b118f95472d5b654'' I Hope this doesn't cause that the parts for writer and draw are annihilated
(In reply to comment #33) > First of all, the patch you partly reverted is my THIRD patch to this bug. Oh Sorry. I only quickly looked through the bug report. > This Patch does: > * Allow you to re-select a custom shape IN CALC when you are editing text by > clicking that object outside the text field. > * Allows you to > select an other custom shape when you are editing text by clicking that > object outside the former text field > even if the point where you are clicking is still inside the non-text area > of that old object Ok and how does this relate to notes handling? Please give me an easy step by step instruction of what I must do to reproduce the problem you fixed. Otherwise it is impossible for me to fix it correctly again. Currently I see 2 ways to fix the crash but I have no idea which one is the correct one to fix your issue. > > What of both patches do you mean with the one with errors? the second one? I > knew that the 2nd was defective (for draw) so I wrote the third. I'm only interested in the Calc changes. > > And I realized that you wrote in your patch > ,, this reverts e80a8b6f14fac6bb6cc7ea55b118f95472d5b654'' > I Hope this doesn't cause that the parts for writer and draw are annihilated No. If you look into the patch I only reverted the parts in sc. The message is the default message of git when you use git revert so it always puts the old commit id int the message but I fixed manually edited the patch.
Precising the Problem/Steps to reproduce. Steps to reproduce obvious calc probs: 1. Create a custom shape. Make it about three as high as the default shape text. 2. Double click it to edit text 3. Write eg. "breadstick". 4. Click above the text. => you dont exit text mode, unlike writer, draw and impress Other trouble: 1. Create a custom shape. Make it about fife times as high as the default shape text. 2. onto its upper half, put a little second custom shape 2. Double click the main shape to edit text 3. Write eg. "breadstick". 4. Click the little shape => you do not select the little shape I found whats wrong with my patch: The Line is guilty: rViewData.GetDispatcher().Execute(aSfxRequest.GetSlot(), SFX_CALLMODE_SLOT | SFX_CALLMODE_RECORD); If we remove it, you can make comments and still use most of my patch. (It won't help against the ,,other trouble'' anymore) So we have to find out somehow how this line causes the crash.
Ah yes, you wondered how it does relate to NOTES handling. Well, either because it terminates some edit mode. I am afraid the notes handling seems to contain unstable or, because my line happens to dereference an empty pointer. Then, I should include this line into an if (&rViewData) { } (I tried, without effect) of course, if you don't use the >>Execute<< line, you dont need the line that gets you rViewData. By the way, where is the code that controls these comments, or notes, anyway?
(In reply to comment #36) > Ah yes, you wondered how it does relate to NOTES handling. > > Well, either because it terminates some edit mode. > I am afraid the notes handling seems to contain unstable > > or, because my line happens to dereference an empty pointer. > > Then, I should include this line into an > > if (&rViewData) > { > } > > (I tried, without effect) > > of course, if you don't use the >>Execute<< line, you dont need the line > that gets you rViewData. > > By the way, where is the code that controls these comments, or notes, anyway? I know why your code crashes and what is wrong. But what did you try to fix in the notes handling? All you explained until now is that you tried to fix something in the custom shapes but that has nothing to do with notes. Did you see anything related to notes that you wanted to fix or are the changes to the notes handling just an accident?
I did NOTHING to them! I dont even know where those routines are.
So the changes, or rather the EFFECTS on the notes handling are an *accident*. But if you know what is going wrong (and it is just this very line), why did you think I did something to the notes function which I didn't even know of when I wrote this patch? This line is intended to switch off the text editing on the newly selected object. So rather than fixing the second described calc issue, I have to correct myself: This line switches off the text mode in both cases.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecfe151546e3c0bcea71c949b9fa35a327d71969 changing the note handling was an error, fdo#55430 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #40) > Markus Mohrhard committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=ecfe151546e3c0bcea71c949b9fa35a327d71969 > > changing the note handling was an error, fdo#55430 > Acoording to your comment that you did not intend to change notes handling I removed the code. This code was only called for notes and therefore wrong.
if( !IsSizingOrMovingNote(rMEvt) ) Means that it is called if I am *NOT* sizing or moving a note! (The ! symbol means inversion) and the condition if ( pView->IsTextEdit() ) is given on ANY text edit, also on custom shapes. And it is clearly seen that it is also called otherwise. I call it from there to terminate text editing on custom shapes. So that means it is missing now and these ,,Notes'' must just have reacted wrongly on the terminating command. Leave the workaround to me ... I add an extra check whether we are editing a note or something else. But the *real error* must be on the memory management of incompletely edited notes - either unstably defined local objects or bad terminating routine. And knows what - If you are editing a note and select ,,Word Art'', you are getting a glitch where the note ceases to be a Note but becomes a large 90° turned text which belongs to a cell but you can't click on. *rofl*.
(In reply to comment #42) > if( !IsSizingOrMovingNote(rMEvt) ) > > Means that it is called if I am *NOT* sizing or moving a note! (The ! symbol > means inversion) > > and the condition > > if ( pView->IsTextEdit() ) > > is given on ANY text edit, also on custom shapes. > > And it is clearly seen that it is also called otherwise. > I call it from there to terminate text editing on custom shapes. > > So that means it is missing now and these ,,Notes'' must just have reacted > wrongly on the terminating command. NO! These calls should not be made at this place. I think you want end the edit mode maybe after line 330 but before that calling GetViewData()->GetDispatcher().Execute(aSfxRequest.GetSlot(), SFX_CALLMODE_SLOT | SFX_CALLMODE_RECORD); is wrong and relies on an implementation detail that it does not crash in all cases. I'm sorry but adding that call in the old place is wrong. This call tells the handling calc shell that the object is actually no longer in focus and can be removed at the next possibility. This is obviously wrong as you are still using the object later. > Leave the workaround to me ... I add an extra check whether we are editing a > note or something else. But not at that place. I'm sorry but it is wrong to call the clean-up in this place. > But the *real error* must be on the memory management of incompletely edited > notes - either unstably defined local objects or bad terminating routine. No. You are calling the clean-up before everything is done. Looking closer at it I think there are a few more cases despite notes that are handled wrongly but I won't look into it until you send a review request. > > And knows what - If you are editing a note and select ,,Word Art'', you are > getting a glitch where the note ceases to be a Note but becomes a large 90° > turned text which belongs to a cell but you can't click on. *rofl*. Please stay friendly. I was just trying to clean up the problems that this patch created. It created a bug that was marked as blocker and prevented some important regression fixes in master. Your patch should not have passed review so I'm sorry that I had to revert it but it was and still is clearly wrong.
Lennard Wasserthal committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b71d3ad1fd71092e4cc85f5bb96b3bc3347e55d2 fdo#55430 allowing click-from-textmode without causing fdo#61025 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.