Created attachment 116315 [details] example for bug I want to trigger a macro, before I change the actual record within a form. For this I have select the name of the BASIC procedure for the event trigger 'before changing record', so that the macro will be executed and a message box with "Test" appears, if this event occurs (to see this, open form of the attached example in edit mode, then open form navigator of this form, then right mouse click (context menu) to 'frm_tbl2' > features > events). I would expect, that the macro fires one time, before the record will be changed, because the meaning of the event is 'trigger before changing the record'. But the macro will be executed, if - the form was opened - two times before the record will be changed - the mouse pointer hovers over the button for changing the record, after the record was changed (one time), so that the real behaviour of this event trigger differs from the expected behaviour described in the context help.
One bug-description for one buggy behavior. I have downloaded the example-file. I can't confirm the event occurs while moving the mouse over the any button in the navigationbar. So I can't confirm this bug. If it is wrong for you the event occurs while opening the form: Open a new bug for this. If it is wrong for you the event occurs two times for different implementations while saving the content of the form: Open a new bug for this. My system: OpenSUSE 13.2 64bit rpm Linux.
Created attachment 116320 [details] screenshot with marked button to change the record I have downloaded the uploaded example again and can reproduce the following behaviour: On Win 8.1 LO Version: 4.4.3.2 Build-ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 (1) I open the example database (2) I open the form 'Table' --> the message box 'Test' appears (3) I change to the next record --> the message box 'Test' appears, if I close it, it appears again (two times) (4) I move the mouse pointer to the button, which changes to the next record (it is red marked in the attached screenshot), but I do not press it --> the message box 'Test' appears, if I close it, it appears again (two times, not one time) --> If I move the mouse pointer first to another button (but do not press it), then the message box appears, if I move the mouse pointer over the marked button. On OpenOffice.org 3.2.1 OOO320m19 (Build:9505) ooo-build 3.2.1.4, Debian package 1:3.2.1-11+squeeze2 (1) I open the example database (2) I open the form 'Table' --> the message box 'Test' appears (3) I change to the next record --> the message box 'Test' appears, if I close it, it appears again (two times) (4) I move the mouse pointer only over the button, which changes to the next record, but I do not press it --> the message box 'Test' appears, if I close it, it appears again (two times) --> If I move the mouse pointer first to another button, then no message box appears in any case.
Cannot reproduce on GNU/Linux either. Maybe this is Windows-specific?
Msgbox must be closed each time before continue, and macros must be enabled. Before I could open the LO 4.4-created example with OOo 3.2.1 (Debian/Squeeze), I had to start a recovering process.
(In reply to christian_kuhn from comment #4) > Msgbox must be closed each time before continue, and macros must be enabled. > Do you think we haven't done this? The messagebox appears when opening the form. The messagebox appears two times when moving from one row to another. The messagebox doesn't appear every time when moving the mouse over the navigationbar. Now I have tried a little bit more and could reproduce the following: 1. Press "Next Record" on the navigationbar. Messagebox appears two times. 2. Move the mouse over navigationbar. If you reach "Next Record" the messagebox appears again two times. The rowcounter changes to next row. 3. Move again over navigationbar, special "Next Record" - nothing happens. 1b,2b,3b. The same with "Previous Record". This has nothing to do with changing the record, only with moving the record by the buttons in the navigationbar. Is this the same buggy behavior you detected? This behavior I could reproduce with OpenSUSE 13.2 64bit rpm Linux and LO 4.4.4.1
Created attachment 116360 [details] expected behaviour for event (german) For Version: 4.4.3.2 Build-ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Gebietsschema: de_DE > Now I have tried a little bit more and could reproduce the following: > 1. Press "Next Record" on the navigationbar. Messagebox appears two times. I agree. > 2. Move the mouse over navigationbar. If you reach "Next Record" the messagebox appears again two times. I agree. This is, what I mean. I would expect, that the macro only will be executed, before the record will be changed I have marked the context help with the expected behaviour for this event trigger in the attached screenshot. For this I must press the "Next record" button. All other buttons without the "Next Record" button will be not selected, if the mouse pointer moves over them. This seems to be buggy. > The rowcounter changes to next row. I cannot confirm. The row counter changes only the row, if I press the "Next Record" button and not, if I move the mouse pointer over it and do not press it. > 3. Move again over navigationbar, special "Next Record" - nothing happens. I agree. For OpenOffice.org 3.2.1 OOO320m19 (Build:9505) ooo-build 3.2.1.4, Debian package 1:3.2.1-11+squeeze2 > 1. Press "Next Record" on the navigationbar. Messagebox appears two times. I agree. > 2. Move the mouse over navigationbar. If you reach "Next Record" the messagebox appears again two times. I can agree for OpenOffice.org 3.2.1 and Debian / Squeeze. If I start from a side of the navigationbar and move the mouse pointer over other buttons and stop then over the "Next Record" button, then a messagebox appears for two times. All other Buttons without the "Next Record" button will be not selected, if the mouse pointer moves over them. Perhaps this is buggy. (This is a difference to my last test, where the messagebox only appeared, when I had closed the second messagebox after changing the record (by pressing the "Next Record" button) and had moved then the mouse directly to the "Next Record" button without pressing it.) > 3. Move again over navigationbar, special "Next Record" - nothing happens. I agree. The message box appears only one time (for two times) after I have changed the record. Please look at the attached screenshot. I have red marked, what I would expect, if I use this event trigger: a macro will be executed one time, if this event appears. This is after I have pressed the "Next Record" button, but before the record will be changed.
(In reply to christian_kuhn from comment #6) > > > The rowcounter changes to next row. > I cannot confirm. The row counter changes only the row, if I press the "Next > Record" button and not, if I move the mouse pointer over it and do not press > it. Rowcounter changes to new row only if there appears a messagebox. Not the event itself enters the new row, but the klick on the messagebox - but this is another bug. Let us first set this bug to new: Event, which has been chosen one time by "Next Record" or "Previous Record", will be executed after moving the mouse over the button of the navigationbar once more. I write down 'once', but there are two implementations for the event so the messagebox appears two times for one event.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still present, see bug 107839, which I believe is a duplicate of this report.
At least insofar as the firing beforeUpdate event is concerned.
Reproduced with Version: 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 Threads CPU : 8; Version de l'OS :Mac OS X 10.12.4; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR.UTF-8); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in: Version: 6.1.1.2 (x64) Build-ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU-Threads: 1; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded
Dear christian_kuhn, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hello, I have downloaded the example again and have got the following results: For: Version: 5.2.7.2 Build-ID: 1:5.2.7-1+deb9u7 CPU-Threads: 6; BS-Version: Linux 4.9; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group 1) If I open the form, then the message box with content "Test" appears, i.e. the subroutine 'Check_rl_term_context' was executed. However, this subroutine was registered for the form event 'Before changing the record', not for 'After loading'. 2) If I press the button to change to the next record, then the message box appears two times (subroutine 'Check_rl_term_context' was called two times per change to the next record), before the record will be changed. 3) If I move the mouse pointer to this button without pressing it after I have changed the record, the message box appears one time. This should not happen. For Version: 6.3.0.0.alpha1 Build-ID: 1:6.3.0~alpha1-2 CPU-Threads: 2; BS: Linux 4.19; UI-Render: Standard; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded First, I had to migrate to Firebird DB. 1) If I open the form, then the message box with content "Test" appears, too. This is the same behaviour as described above. 2) If I press the button to change to the next record, then the message box appears two times, then the record will be changed as described above. But then, the message box appears two times again, and the record will be changed to the next record for a second time. In summary, per click to the button, the message box appears four times, and the record will be changed two times. I would expect, that the record will be changed one time, not two times. 3) If I move the mouse pointer tho this button without pressing it, nothing happens (no message box appears). This is the expected behaviour. Best regards, Christian
Dear christian_kuhn, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hello, the bug is still present, I can confirm the behaviour as described in comment 15 (for Version: 6.3.0.0.alpha1, without migration to Firebird) using Version: 7.1.5.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: de-DE Debian package version: 1:7.1.5-2~bpo11+1 Calc: threaded Regards, Christian
Have opened a new bug for this. Changed the macro a little bit to get only one event when changing record. Sub Check_rl_term_context(oEvent AS OBJECT) oForm = oEvent.Source IF hasUnoInterfaces(oForm, "com.sun.star.form.XForm" ) THEN MsgBox("Test") END IF End Sub So we have only one buggy behavior to look for: Moving to next or previous row while moving mouse over navigation bar.