Created attachment 88673 [details] Describes how to reproduce and a macro tells you the "active" workbook, sheet, cell. VBA macros in LibreOffice consider the "last opened" spreadsheet with VBA as the active Document/Sheet/Cell. Changing to a previously opened XLS file does not switch the active document, and closing the "last opened" spreadsheet causes VBA references to the ActiveWhatever to Basic Runtime Error. The test documents from Bug 54721 show this. I'm not reopening that bug based on the comments in it - which say that a new bug should be filed instead. In my testing, it appears that only documents that contain VBA code affect this. Opening simple .xls files without macros doesn't break the "active" document. Tested on 4.0.4 (Linux) and 4.1.2 (Windows)
Tested on 4.0.0.3 (Win) with the same problem. Tested on 3.6.7 (Win) and this problem was not there. So looks like a 4.0 regression.
Confirmed that this is still a bug in 4.1.3. Changing importance to high, since this is a regression from 3.6. Also, ActiveDocument is the default context for many macro commands, and I couldn't find a programming work-around for the bug. When you close the last opened .xls file, the now undefined ActiveDocument references cause this VB error: Basic runtime error '1' Type: com.sun.star.lang.DisposedException Message: <blank>
(This is an automated message.) Setting priority to highest as this is a 4.1 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
confirmed that the bug still exists in 4.1.6.2 and 4.2.4.1
moving it to mab4.2 list since 4.1.x is EOL
I'm sorry but that is surely not a MAB. VBA support is only a feature that works to some degree and is only helpful for interoperability for a small group of people.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I tried to bibisect this bug (downloaded bibisect-43all), however it seems that only up to the x.x.0 builds are included in bibisect. The bug appears from the earliest 3.5 builds, but was fixed somewhere in 3.6.x. So, in bibisect I could never find a "place" where the bug was fixed, since it is broken again in 4.0.0. Whiteboarding this as NotBibisectable.
In the description, I wrote 'closing the "last opened" spreadsheet causes VBA references to the ActiveWhatever to Basic Runtime Error.' Somewhere along the line, this VBA error part has been fixed (fix sometime earlier, but testing today with Version: 4.4.0.0.alpha0+ Build ID: 1a91abb451806bd93a08953c6a1afdb88995705e). I tried to find the fix commit location with bibisect, but it hasn't been fixed in any of the bibisect series (still an error with "git checkout latest" Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e). Now the super-interesting part - EVERYTHING WORKS NOW when the "last" document has been closed. I opened up 4 copies of the test document. At first, the macro in all of them points to the LAST opened document (the reason for the bug report). However, if I close the LAST OPENED document, the ActiveDocument status now PROPERLY switches between the remaining three!!!
The problematic code is in vbahelper/source/vbahelper/vbahelper.cxx function getCurrentDoc( const OUString& sKey ). This function does NOT return the current document, but only the last opened document. If the last opened document is closed, this function raises an exception [referencing xModel->getURL()]. When the exception is raised, the function "getCurrentExcelDoc" falls back to getThisExcelDoc() which works properly. So, a quick bandaid would be to always call "getThisExcelDoc" instead of "getCurrentDoc" since the "current" doc isn't correct anyway. THISdoc will USUALLY be the activeDoc (but not necessarily). I'll look a bit more into what getCurrentDoc() does and see if I can figure out how to properly fix it, but at the moment I don't understand what it is trying to do.
(In reply to comment #10) This is the code line that causes the exception: SAL_INFO("vbahelper", "Have model points to url " << xModel->getURL());
s_aRegisteredVBAConstants in sfx2/source/doc/objxtor.cxx is never SET. A name for an XInterface is searched for, but no XInterfaces are ever entered into this map. If each Excel document is registered in here as "ThisExcelDoc", then SetCurrentComponent()/lclGetVBAGlobalConstName() will set the GlobalUNOConstant for ThisExcelDoc. Alternatively, if the document had a 'ThisVBADocObj' property assigned as 'ThisExcelDoc', lclGetVBAGlobalConstName() might work. I don't see anywhere where 'ThisVBADocObj'/UNO_NAME_VBA_DOCOBJ is assigned any value in the code. So basically, nothing about the lclGetVBAGlobalConstName seems to function. It is only used in objxtor.cxx, so all of this code can be removed I think.
bug (re)introduced around Nov 28, 2012 by a patch marked as date 25-Mar-2011 by Daniel Rentz @ oracle.com, comment "calcvba: #164410# improve VBA compatibility implementation in various areas:". At this time SC_UNO_VBADOCOBJ/"ThisVBADocObj" was changed to SC_UNO_VBAGLOBNAME/ "VBAGlobalConstantName". This appears to be rebasing the code on OOo. Simply replacing 'ThisVBADocObj' in objxtor.cxx to produce this line: xProps->getPropertyValue("VBAGlobalConstantName") >>= aConstName; will fix the problem. That matches the OOo code. "ThisVBADocObj" is also referenced in LO Writer (but not in OOo Writer) (sw/inc/unoprnms.hxx defines UNO_NAME_VBA_DOCOBJ as "ThisVBADocObj".) It doesn't appear that anything uses this code, so it should be safe to "tinker" with it. UNO_NAME_VBA_DOCOBJ introduced into Word around October 2010 by Noel Power, comment "initial commit for vba blob ( not including container_control stuff )" The WORD portion probably needs the same fix as happened in Bug 54721, changing sw/source/core/unocore/unomap.cxx: { OUString(UNO_NAME_VBA_DOCOBJ), WID_DOC_VBA_DOCOBJ, cppu::UnoType< cppu::UnoSequenceType<css::beans::PropertyValue> >::get(), PropertyAttribute::READONLY, 0}, to: {OUString(UNO_NAME_VBA_DOCOBJ), WID_UNO_NAME_VBA_DOCOBJ, cppu::UnoType<OUString>::get(), beans::PropertyAttribute::READONLY, 0}, and fixing UNO_NAME_VBA_DOCOBJ in sw/source/core/unocore/unomap.cxx and sw/source/uibase/uno/unotxdoc.cxx (or sw/source/core/uibase/uno/).
submitted patch for review: https://gerrit.libreoffice.org/#/c/11725/
Justin's patch was accepted and pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4108bd9b7a41eaa0f3bf8b8173f27f57e009ee34 patch also cherrypicked for LO 4.3, pending review. patch failed to cherry-pick for LO 4.2.7 rc1. Patch submitted for ThisWordDoc, pending review: https://gerrit.libreoffice.org/#/c/11827/
correction: ThisWordDoc patch is at https://gerrit.libreoffice.org/11842/
ThisWordDoc patch has been accepted into the 4.4 development tree. The main patch was accepted into the 4.3 stable tree. It will be included in 4.3.4 due Dec 21, 2015. Thanks to Noel Power and Samuel Mehrbrodt for helping and encouraging me in tracking down the fix and helping to submit and move the patch through the development process.
Migrating Whiteboard tags to Keywords: (NotBibisectable) [NinjaEdit]