Created attachment 78376 [details] test file Seems sometime we get a situation where an import ole control won't fire, event bindings in vba for ole controls are dynamic, in other words the existence of the appropriately named VBA event handler procedure is enough to ensure that handler is associated/bound to various events of the associated control. However to prevent 'normal' controls behaving the same way there is a mechanism to prevent that event handling being exercised. It's controlled by the 'GenerateVbaEvents' property for each control. The GenerateVbaEvents property is examined by the forms layer when inserting controls. However it seems that in some cases the order in which things are called is not quite expected, e.g. normally we would expect that all the controls are read ( and properties including GenerateVbaEvents applied ) before the forms layer code that examines 'GenerateVbaEvents' ( see OInterfaceContainer::implInsert in forms/source/misc/InterfaceContainer.cxx ) is called. I have come across at least one example where this is causing problem ( see attachment )
** 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.0.0.5 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Hi Noel, I'm setting this ticket back to NEW as it has been inactive for more than 3 months. Feel free to assign it back to you if you're still working on this. Regards
Created attachment 128296 [details] macro.xlsm: macro.xls saved by MSO2013 into xlsm format The original test document (noclick.xlsm) works now (thanks to Bug 53042??), but mine still doesn't. The complication here is that it originated life as a .xls file. The buttons work in both Word2003 and Word2013, but not in LO. Tested from Linux/Windows using LO5.3/5.1.
(In reply to Justin L from comment #3) caused by a regression in LO5.1 by author Markus Mohrhard <markus.mohrhard@googlemail.com> 2015-10-24 07:45:58 (GMT) commit d4743045a0b320449d07a957463a76bb8b13f939 the cells need to be imported before we handle charts, tdf#81396 fix: vbaproject::attachMacros needs to run AFTER the shapes are imported since macros can attach to the shaps.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b41e7b817e1e214582505d28d0cc36d741fa9979 tdf#63846 assign macros after VBA project fully loaded. It will be available in 5.3.0. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=255c751c48955b56b96e1cf945b800ee4c1c917c&h=libreoffice-5-2 tdf#63846 assign macros after VBA project fully loaded. It will be available in 5.2.4. 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.