When trying to set an action to a graphical button nothing happens. Only the reset-function will work. I could not find this bug, but it won't work also in OOo 3.3.
NOT reproducible with and first sample from "Bug 37024 - UI: WEB-View for Form layout no longer available " <https://bugs.freedesktop.org/show_bug.cgi?id=37024> I tried Navigation toolbar, everything worked fine. To be honest, I have no idea what problem reporter is talking about. This is not a valid bug report, any useful information is missing. Robert, you should know better, please contribute additional information concerning your OS, LibO version, due to Bug 44204#C1!
Created attachment 57604 [details] Open the form and try the graphical buttons, which are added. I have not realised that you could think: graphical buttons are the navigation-bar and so on. These buttons are control-fields of a form. And these buttons wont work under Linux-rpm in LibreOffice 3.3.4 and in LibreOffice 3.5. And these Buttons wont't work (not our problem, you might think) in OOo 3.3 under Linux-rpm, Windows and Mac. I can not realise that nobody had recognised it before. Robert
[Reproducible] with "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]" Also a problem with 3.4.5, 3.5.0 Still [Reproducible] with "LOdev 3.6.0alpha0+ English UI/Locale [Build ID: aa7e105-b2dd236-9eed775-d06f752-4dba2d1 (libreoffice-3-5-branch-point)]" {Win-x86@9-Voreppe Win32 pull time 2012-02-14 16:17:23}. OS: German WIN7 Home Premium (64bit) Inherited from OOo, also a Problem with OOo 3.1.1, 3.3, 3.4Beta; I did not find an AOOo Issue. I attached a modified version of reporter's database showing that normal Push Buttons work as expected. Lionel: One for you? Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug.
Created attachment 57621 [details] Enhanced sample document Enhanced sample document additionally shows that "normal" buttons work fine.
For the record, on pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Adding self to CC if not already on
*** Bug 89169 has been marked as a duplicate of this bug. ***
** 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.6 or 5.2.3 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-20170103
Bug still exist in Version: 5.2.4.2 Build-ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0 CPU-Threads: 4; BS-Version: Linux 4.1; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group Also tested with LO 5.4.0.0.alpha0. Same behavior. Nothing happens if I click on any "ImageButton" of the form.
OK, I have found a workaround: You could set the action to "Open document/web page" and then type for URL .uno:NextRecord ... so you get the action "Next Record" Seems the actions have simply been forgotten ...
** 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
On pc Debian x86-64 with master sources updated yesterday, I can still reproduce this.
Bug still exists with LO 6.1.5.2 on OpenSUSE 15, 64bit rpm Linux.
Bug still exists in LO 6.3.4 on Windows 10 (64 bits). Database-type does not matter. Unfortunately the suggested workaround does not work either (in my case): The settings are accepted when editing the form, but nothing happens when used.
(In reply to Tom from comment #15) > Bug still exists in LO 6.3.4 on Windows 10 (64 bits).
Lionel: following Robert's comment about using ".uno:NextRecord", I gave a try with this patch: diff --git a/extensions/source/propctrlr/pushbuttonnavigation.cxx b/extensions/source/propctrlr/pushbuttonnavigation.cxx index 3d1bf748c712..786ef8862eb6 100644 --- a/extensions/source/propctrlr/pushbuttonnavigation.cxx +++ b/extensions/source/propctrlr/pushbuttonnavigation.cxx @@ -43,7 +43,7 @@ namespace pcr { ".uno:FormController/moveToFirst", ".uno:FormController/moveToPrev", - ".uno:FormController/moveToNext", + ".uno:NextRecord", ".uno:FormController/moveToLast", ".uno:FormController/saveRecord", ".uno:FormController/undoRecord", diff --git a/forms/source/inc/frm_strings.hxx b/forms/source/inc/frm_strings.hxx index 06d3f8cb148b..af69996206c5 100644 --- a/forms/source/inc/frm_strings.hxx +++ b/forms/source/inc/frm_strings.hxx @@ -274,7 +274,7 @@ namespace frm #define URL_FORM_RECORDCOUNT ".uno:FormController/RecordCount" #define URL_RECORD_FIRST ".uno:FormController/moveToFirst" #define URL_RECORD_PREV ".uno:FormController/moveToPrev" - #define URL_RECORD_NEXT ".uno:FormController/moveToNext" + #define URL_RECORD_NEXT ".uno:NextRecord" #define URL_RECORD_LAST ".uno:FormController/moveToLast" #define URL_RECORD_SAVE ".uno:FormController/saveRecord" #define URL_RECORD_UNDO ".uno:FormController/undoRecord" diff --git a/svx/source/inc/fmurl.hxx b/svx/source/inc/fmurl.hxx index a354eae59e84..bd6c9837e047 100644 --- a/svx/source/inc/fmurl.hxx +++ b/svx/source/inc/fmurl.hxx @@ -24,7 +24,7 @@ #define FMURL_FORM_RECORDCOUNT ".uno:FormController/RecordCount" #define FMURL_RECORD_MOVEFIRST ".uno:FormController/moveToFirst" #define FMURL_RECORD_MOVEPREV ".uno:FormController/moveToPrev" -#define FMURL_RECORD_MOVENEXT ".uno:FormController/moveToNext" +#define FMURL_RECORD_MOVENEXT ".uno:NextRecord" #define FMURL_RECORD_MOVELAST ".uno:FormController/moveToLast" #define FMURL_RECORD_MOVETONEW ".uno:FormController/moveToNew" #define FMURL_RECORD_UNDO ".uno:FormController/undoRecord" Then I modified the form to use next record for the image control since it was broken with the patch then it worked! So do you think it's the right way or should we stick to urls like: .uno:FormController/<action> ? I mean, I'm not sure these uno/FormController work in other cases so even if the each exiting forms will have to be modified, since it didn't work at first place, I think it might be the right move.
Wow, that's a strange bug indeed. Text button and image button seem to have quite different implementations, not sure why. I see that text buttons, in forms/source/component/Button.cxx, have some special treatment of URLs starting with ".uno:FormController/", in function OButtonControl::getModelUrlFeatureId: // are we a URL button? if ( eButtonType == FormButtonType_URL ) { // is it a feature URL? if ( isFormControllerURL( sUrl ) ) { nFeatureId = OFormNavigationMapper::getFeatureId( sUrl ); } } My guess is that the same treatment must happen for image buttons, but doesn't. Probably should happen either somewhere in ImageButton.cxx or in the parent class clickableimage.cxx
(In reply to Lionel Elie Mamane from comment #18) > ... > My guess is that the same treatment must happen for image buttons, but > doesn't. Probably should happen either somewhere in ImageButton.cxx or in > the parent class clickableimage.cxx Thank you for the feedback. I'll take a look. What I liked in the patch I quoted is the fact we could use same uno commands as others. If we fix this bug by finding the way to deal with .uno:FormController/*, we won't be able to remove these since it'll bring some compatibility regression.
Lionel: I finally found the missing element for clickable image. dispatch/interceptor part was difficult to track down. I submitted https://gerrit.libreoffice.org/c/core/+/107037
(In reply to Julien Nabet from comment #20) > Lionel: I finally found the missing element for clickable image. > dispatch/interceptor part was difficult to track down. > I submitted https://gerrit.libreoffice.org/c/core/+/107037 Sorry Lionel the comment of my patch didn't explain anything, I was quite tired yesterday and eager to submit the patch :-) Let's start with non image button which work. When entering the form, the specific dispatch mechanism for these urls is prepared: Thread 1 "soffice.bin" hit Breakpoint 1, frm::OFormNavigationHelper::queryDispatch (this=0x7781dc8, _rURL=...) at forms/source/helper/formnavigation.cxx:263 263 return m_pFeatureInterception->queryDispatch( _rURL ); (gdb) p _rURL $1 = (const com::sun::star::util::URL &) @0x7783208: {Complete = ".uno:FormController/moveToFirst", Main = ".uno:FormController/moveToFirst", Protocol = ".uno:", User = "", Password = "", Server = "", Port = 0, Path = "FormController/moveToFirst", Name = "", Arguments = "", Mark = ""} (gdb) bt #0 frm::OFormNavigationHelper::queryDispatch(com::sun::star::util::URL const&) (this=0x7781dc8, _rURL=...) at forms/source/helper/formnavigation.cxx:263 #1 0x00007f85f9087ec1 in frm::OFormNavigationHelper::connectDispatchers() (this=0x7781dc8) at forms/source/helper/formnavigation.cxx:200 #2 0x00007f85f9087353 in frm::OFormNavigationHelper::updateDispatches() (this=0x7781dc8) at forms/source/helper/formnavigation.cxx:146 #3 0x00007f85f8eef7ee in frm::OButtonControl::modelFeatureUrlPotentiallyChanged() (this=0x7781c80) at forms/source/component/Button.cxx:623 #4 0x00007f85f8eef701 in frm::OButtonControl::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) (this=0x7781c80, _rxModel= uno::Reference to (UnoControlButtonModel *) 0x393af28) at forms/source/component/Button.cxx:607 #5 0x00007f864a52ac26 in sdr::contact::(anonymous namespace)::ControlHolder::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) const (this=0x7fffa2d6e700, _m=uno::Reference to (UnoControlButtonModel *) 0x393af28) at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:187 Notice URL: {Complete = ".uno:FormController/moveToFirst", Main = ".uno:FormController/moveToFirst", Protocol = ".uno:", User = "", Password = "", Server = "", Port = 0, Path = "FormController/moveToFirst", Name = "", Arguments = "", Mark = ""} It's also during form opening that the method "getModelUrlFeatureId" you quoted in your previous comment is called: #0 frm::OButtonControl::getModelUrlFeatureId() const (this=0x73d2820) at forms/source/component/Button.cxx:655 #1 0x00007f85f8eef787 in frm::OButtonControl::modelFeatureUrlPotentiallyChanged() (this=0x73d2820) at forms/source/component/Button.cxx:618 #2 0x00007f85f8eef701 in frm::OButtonControl::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) (this=0x73d2820, _rxModel=uno::Reference to (UnoControlButtonModel *) 0x3e49c88) at forms/source/component/Button.cxx:607 #3 0x00007f864a52ac26 in sdr::contact::(anonymous namespace)::ControlHolder::setModel(com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> const&) const (this=0x7fffa2d6e700, _m=uno::Reference to (UnoControlButtonModel *) 0x3e49c88) at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:187 Then once in the form, each click on one of these button calls: #0 frm::OFormNavigationHelper::dispatch(short) const (this=0x7784578, _nFeatureId=5) at forms/source/helper/formnavigation.cxx:287 #1 0x00007f85f8eeeef3 in frm::OButtonControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x7784430, _bNotifyListener=false, _rEvt=...) at forms/source/component/Button.cxx:498 #2 0x00007f85f8eeed58 in frm::OButtonControl::OnClick(void*) (this=0x7784430) at forms/source/component/Button.cxx:478 #3 0x00007f85f8eee5c0 in frm::OButtonControl::LinkStubOnClick(void*, void*) (instance=0x7784430, data=0x0) at forms/source/component/Button.cxx:429 #4 0x00007f864739e9e8 in Link<void*, void>::Call(void*) const (this=0x6e1ec78, data=0x0) at include/tools/link.hxx:111 #5 0x00007f864739abee in ImplHandleUserEvent(ImplSVEvent*) (pSVEvent=0x6e1ec70) at vcl/source/window/winproc.cxx:1990 Now, let's take a look at image button which doesn't work. When opening form there's some preparation with: #0 frm::OImageButtonModel::describeFixedProperties(com::sun::star::uno::Sequence<com::sun::star::beans::Property>&) const (this=0x6f92d40, _rProps=empty uno::Sequence) at forms/source/component/ImageButton.cxx:78 #1 0x00007f85f8fd2c7c in frm::OControlModel::describeFixedAndAggregateProperties(com::sun::star::uno::Sequence<com::sun::star::beans::Property>&, com::sun::star::uno::Sequence<com::sun::star::beans::Property>&) const (this=0x6f92d60, _out_rFixedProperties=empty uno::Sequence, _out_rAggregateProperties=empty uno::Sequence) at forms/source/component/FormComponent.cxx:1040 #2 0x00007f85f9070f4c in frm::PropertyBagHelper::impl_ts_getArrayHelper() const (this=0x6f92ec8) at forms/source/component/propertybaghelper.cxx:154 #3 0x00007f85f8f6e7a5 in frm::PropertyBagHelper::getInfoHelper() const (this=0x6f92ec8) at forms/source/inc/propertybaghelper.hxx:112 #4 0x00007f85f8fd2e9e in frm::OControlModel::getInfoHelper() (this=0x6f92d60) at forms/source/component/FormComponent.cxx:1056 #5 0x00007f85f8fd2dde in frm::OControlModel::getPropertySetInfo() (this=0x6f92d60) at forms/source/component/FormComponent.cxx:1051 #6 0x00007f85f8fd2e6d in non-virtual thunk to frm::OControlModel::getPropertySetInfo() () at forms/source/component/FormComponent.cxx:1051 #7 0x00007f8643d7efc2 in xmloff::OControlImport::createElement() (this=0x3e6e210) at xmloff/source/forms/elementimport.cxx:1039 and each click on image button is done here: Thread 1 "soffice.bin" hit Breakpoint 5, frm::OClickableImageBaseControl::actionPerformed_Impl (this=0x6e27910, bNotifyListener=false, rEvt=...) at forms/source/component/clickableimage.cxx:330 330 xDisp->dispatch( aHyperLink, aProps ); (gdb) bt #0 frm::OClickableImageBaseControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x6e27910, bNotifyListener=false, rEvt=...) at forms/source/component/clickableimage.cxx:330 #1 0x00007f85f9027245 in frm::OImageButtonControl::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x6e27910, e=...) at forms/source/component/ImageButton.cxx:207 #2 0x00007f8649721097 in MouseListenerMultiplexer::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x783b738, evt=...) at toolkit/source/helper/listenermultiplexer.cxx:106 #3 0x00007f8649721097 in MouseListenerMultiplexer::mousePressed(com::sun::star::awt::MouseEvent const&) (this=0x6e2ebc8, evt=...) at toolkit/source/helper/listenermultiplexer.cxx:106 #4 0x00007f86494cda84 in VCLXWindow::ProcessWindowEvent(VclWindowEvent const&)::$_2::operator()() const (this=0x79f44c0) at toolkit/source/awt/vclxwindow.cxx:726 let's take a look at URL: (gdb) p aHyperLink $3 = {Complete = ".uno:OpenHyperlink", Main = ".uno:OpenHyperlink", Protocol = ".uno:", User = "", Password = "", Server = "", Port = 0, Path = "OpenHyperlink", Name = "", Arguments = "", Mark = ""} all the info are in the second arg of "dispatch", "aProps": (gdb) p aProps $4 = uno::Sequence of length 3 = {{Name = "URL", Handle = 0, Value = uno::Any("string": ".uno:FormController/moveToNext"), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}, { Name = "FrameName", Handle = 0, Value = uno::Any("string": "_blank"), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}, {Name = "Referer", Handle = 0, Value = uno::Any("string": ""), State = com::sun::star::beans::PropertyState::PropertyState_DIRECT_VALUE}} Now let's take a look at m_pFeatureInterception declared the same way as ::std::unique_ptr< ControlFeatureInterception > in forms/source/inc/formnavigation.hxx and forms/source/component/clickableimage.hxx ControlFeatureInterception is a "helper class for controls which allow some of their features to be intercepted" (see https://opengrok.libreoffice.org/xref/core/forms/source/inc/controlfeatureinterception.hxx?r=f0c8312b#48) (Argh, I must go back to work, I'll keep on later)
Let's go on with m_pFeatureInterception which is ControlFeatureInterception. This last one is initialized with param - m_xORB (css::uno::Reference< css::uno::XComponentContext >) in formnavigation.cxx (the OK case) - _rxFactory in clickableimage.cxx (the KO case) ... Then the more I try to understand the rest, the more I got lost with all these dispatch, m_xORB, references, ... The only thing I'm sure is the patch made this work. I'll push this one on master and let people give it a try. If someone complains about it, don't hesitate to revert. I'm quite fed up of all these tricky mechanisms in some parts of LO.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/07be45d03f80fa681c697ca9f5a13084a81c7a26 tdf#46579: fix form fields 'Image Button' in Forms It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/6b5ca41c5d78e6a45f7a39d99c5a7ae283d243de tdf#46579: fix form fields 'Image Button' in Forms It will be available in 7.1.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/45963cfb6b453cf18aaa7534f20c35a38975dc89 tdf#46579: fix form fields 'Image Button' in Forms It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a444a8dd40cf7035c44ee8ef168be2b3e3144c86 tdf#140151: revert fix for tdf#46579 which caused regression It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patch caused regression (see tdf#140151). So I reverted it on master, and the revert waits for review for 7.1 and 7.0 branches. No idea at all what's the pb of regression. => revert back to NEW and uncc myself.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/9567639d6a649cffc9f1a965a11b5b202b241179 tdf#140151: revert fix for tdf#46579 which caused regression It will be available in 7.1.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/2a27ff2190a40afe806bbf3577b641390047e209 tdf#140151: revert fix for tdf#46579 which caused regression It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Using Windows 11 on laptop 16GB and Windows 10 Home on desktop, LO version 7.3.5.2 (64 bits), database Firebirds external (server) I can confirm that the issue still exists. Trying to use earlier mentioned workarounds is NOT recommanded either: causing LO crash or freeze.
More information and correction: Correction: The mentioned workaroud does work but with restrictios, see below. Other findings: 1. Unlike implemented for push-buttons, no "click-effect" is implemented for image-buttons. User therefore does not clearly see whether or not a button has been used. 2. Image-buttons used for navigation are not disabled when not applicable (i.e. first and previous record buttons are not disabled when record-pointer at first record of a recordset). This is working correctly when using push-buttons with a navigation action. 3. When opening a second form without closing the current form, and then using the first form again, navigation does not work anymore when using image-buttons. It seems the form has lost its record-pointer. 4. When using image-buttons in combination with a called macro to perform the required record action everything works correctly, except disabling as mentioned before. Used coding in that case: sFormName = Split(thiscomponent.Title," : ")(1) 'required? oForm = thisComponent.drawpage.forms.getByName(sFormName) 'required? oDocument = ThisComponent.CurrentController.Frame oDispatcher = createUnoService("com.sun.star.frame.DispatchHelper") oDispatcher.executeDispatch(oDocument ,".uno:FirstRecord","",0,Array()) Interesting finding: if in addition to image-buttons also push-buttons are defined with action navigation on the form disabling reacts for these buttons if the image-buttons are used. I do realize that these issues have mainly a "cosmetic" character, since push-buttons can be used instead, but the concerned functionality should for image-buttons either be corrected or not made available.
Dear Robert Großkopf, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Bug appears with LO 7.5.1.2 on OpenSUSE 15.4 64bit rpm Linux. Nothing changed.
Still in Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded