Created attachment 178145 [details] MyBaseTest I want my cycle to be: "active recording" to force the user to clicked on a "Save" button The action of the button is positioned to "save active registration" The form event "before registration" calls a control macro. The form event "after registration" calls a macro of "reporting". As soon as the button is changing the button is activated (Enabled = True) which is normal If you click on the control macro before recording is well done, but the aftermarket macro is not launched and the registration not performed which probably causes a non-update of the form of the form (form.Ismodifier = True) and therefore causes an error if we close the form by the "X" button of the window! see : https://ask.libreoffice.org/t/enregistrer-lenregistrement-actif-ne-fonctionne-pas-en-7-3-0/73638
Hi Reproduced on Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Steps to reproduce 1. Open the attached database (enable macro execution) 2. Open the Exemple form 3. Update the content of a text field (e.g. replace "mm" with "mma") Expected & actual result : button "Enregistrer" (save) enabled 4. Click the button Expected results: message box "coucou" & record saved Actual result: no message box, record not saved The event "After record action" does not trigger the macro Was Ok in 7.2 Best regards
Have tested this one. Note: oControl.String will only show the saved string, not a changed content. oControl.CurrentValue will do this. Seems the result of the function, which is executed "Before record actin" isn't submitted back to the form. It will be executed (tested with msgbox), but it will stop saving the data and so the event "After record action" will never appear. Works well in LO 7.2.5.2, fails in LO 7.3.0.3. So a regression.
Bibisected to the 7.3 backport of the following commit using repo bibisect-linux-64-7.3. Adding CC: to Mike Kaganski. https://cgit.freedesktop.org/libreoffice/core/commit/?id=822998f1dc202aba7a558767f641687aef0c1148 author Mike Kaganski <mike.kaganski@collabora.com> 2021-12-22 14:55:01 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2021-12-22 16:39:32 +0100 tdf#143582: Avoid error on clearing leftover return value of a method
This is not a bug. The approveRowChange action is configured to call ControleSaisie. The latter starts with: > Function ControleSaisie(oEvt As object) > Dim oForm As Object , oControl As Object > > 'appellé depuis l'évènement de formulaire ' AVANT enregistrment ' > > If oEvt.Source.ImplementationName <> "org.openoffice.comp.svx.FormController" Then Exit Function > ... > ControleSaisie = True It means that for every oEvt.Source.ImplementationName that is not "org.openoffice.comp.svx.FormController", it returns a default value. Basic language defines that for Variant (a default return value type), the default value is empty, which, when converted to Boolean, gives False. Pressing "Enregistrer" triggers two calls to ControleSaisie: first with oEvt.Source.ImplementationName equal to "org.openoffice.comp.svx.FormController", which returns True (set later in the function), and then with "com.sun.star.comp.forms.ODatabaseForm". The second one returns early, exactly in this test. According to language rules, it must be equal to returning False, which for approveRowChange action is equal to "do not approve the change". The "correct" (actually not) behavior in 7.2 was a side effect of the fixed bug 143582, which didn't clear the result of previous call of the function, so the next time it got executed, without explicit assignment of its value, it returned not the default value, but the previous result. And based on *accidental* order of events (first org.openoffice.comp.svx.FormController, returning True, and then com.sun.star.comp.forms.ODatabaseForm, not defining the return value and returning not cleared previous result), that happened to work as user expected. The correct variant of ControleSaisie should start like this: > Function ControleSaisie(oEvt As object) > ControleSaisie = True ' Approve by default > Dim oForm As Object , oControl As Object > > 'appellé depuis l'évènement de formulaire ' AVANT enregistrment ' > > If oEvt.Source.ImplementationName <> "org.openoffice.comp.svx.FormController" Then Exit Function > ...
(In reply to Mike Kaganski from comment #4) > > If oEvt.Source.ImplementationName <> "org.openoffice.comp.svx.FormController" Unrelated to this issue: note also that ImplementationName is not meant to be stable API. We can change it at any time, and building your macros to depend on the names is error-prone. If needed, you should check the *type* of the object (checking its supported services, or using HasUnoInterfaces function) instead. E.g., see tdf#111811.
(In reply to Mike Kaganski from comment #5) > (In reply to Mike Kaganski from comment #4) > > > If oEvt.Source.ImplementationName <> "org.openoffice.comp.svx.FormController" > > Unrelated to this issue: note also that ImplementationName is not meant to > be stable API. We can change it at any time, and building your macros to > depend on the names is error-prone. If needed, you should check the *type* > of the object (checking its supported services, or using HasUnoInterfaces > function) instead. > > E.g., see tdf#111811. Bravo ..... I have not HasUnoInterfaces propertie in Form ?§ Are you sure services' name don't change ;) Take me an example please
(In reply to TISSENDIER Pierre from comment #6) > I have not HasUnoInterfaces propertie in Form ?§ HasUnoInterfaces is not a property, but Basic function [1]. > Are you sure services' name don't change ;) Yes, they are part of published API, and thus are fixed. You could read about that in the linked issue. > Take me an example please Example of what? I gave you some information to help you avoid possible problems with your code. If needed, you may ask for further help writing code at e.g. https://ask.libreoffice.org/ [1] https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03104400.html
(In reply to Mike Kaganski from comment #7) > (In reply to TISSENDIER Pierre from comment #6) > > I have not HasUnoInterfaces propertie in Form ?§ > > HasUnoInterfaces is not a property, but Basic function [1]. > > > Are you sure services' name don't change ;) > > Yes, they are part of published API, and thus are fixed. You could read > about that in the linked issue. > > > Take me an example please > > Example of what? > > I gave you some information to help you avoid possible problems with your > code. If needed, you may ask for further help writing code at e.g. > https://ask.libreoffice.org/ > > [1] > https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03104400.html Thank you.
Have found this hint: https://bz.apache.org/ooo/show_bug.cgi?id=110324#c5 hasUnoInterface( <source_object>, "com.sun.star.form.XForm" ) and "com.sun.star.form.component.DataForm" are part of the published API (Post is from 2010, OOo 3.2
(In reply to Robert Großkopf from comment #9) > "com.sun.star.form.component.DataForm" > > are part of the published API (Post is from 2010, OOo 3.2 Sorry, what implied that? Some random answer suggested to check it, but immediately writes: > It is possible, but pretty unlikely, that this string changes in the future (it > didn't change the last 10 years, by the way) It is absolutely clear from that answer that "com.sun.star.form.component.DataForm" is *not* part of the published API.
(In reply to Mike Kaganski from comment #10) Oh - please ignore me - it is about service name, not about implementation name! I should read more carefully, and stop writing before comprehending. Yes, service name is part of API, indeed. I'm sorry.