Bug 38230 - Basic module sticks to Base container
Summary: Basic module sticks to Base container
Status: RESOLVED DUPLICATE of bug 52076
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
3.5.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2011-06-13 01:54 UTC by Andreas Säger
Modified: 2014-07-24 07:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

The file without the module (108.08 KB, application/vnd.sun.xml.base)
2011-11-26 14:35 UTC, Julien Nabet
Shows the empty folder "Standard" with no module (27.40 KB, image/png)
2012-10-10 19:01 UTC, Robert Großkopf

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Säger 2011-06-13 01:54:12 UTC
I'm sure this had been a OOo problem for several times, so it could be a regression or something. http://user.services.openoffice.org/en/forum/download/file.php?id=11663 contains an unneeded Basic module on database level. It is irremovable in the GUI of OOo3.4beta, LibO 3.3.2 and LibO3.4.0.
Comment 1 Julien Nabet 2011-11-26 05:31:55 UTC
Could you confirm the pb is still there on 3.4.4 ?
Could you give the name or attach a screenshot of the unneeded Basic Module on database level ?
Comment 2 Andreas Säger 2011-11-26 13:00:55 UTC
Screenshot? Does that mean that you are unable to download and open my document, remove the one and only module from it, save and reopen the same document?

After some testing I do not use LibreOffice 3.4 anymore and I'm afraid that 3.3.4 will be the last version of LibreOffice I will ever use.
Comment 3 Julien Nabet 2011-11-26 13:37:25 UTC
(In reply to comment #2)
> Screenshot? Does that mean that you are unable to download and open my
> document, remove the one and only module from it, save and reopen the same
> document?
> After some testing I do not use LibreOffice 3.4 anymore and I'm afraid that
> 3.3.4 will be the last version of LibreOffice I will ever use.

It only means I know almost nothing about macros but I learnt how to compile LO and took a look at the error messages. It's not much but sometimes it may help :-)
Comment 4 Alex Thurgood 2011-11-26 14:17:04 UTC
Hi Andreas,

From reports I have seen on the French user list, the problem isn't just limited to ODB files, but also any other ODF document for which a user would like to remove a Basic module.

Comment 5 Drew Jensen 2011-11-26 14:34:33 UTC
Using Libo 3.4.4 under Ubuntu 11.04 (64bit) - I was able to remove modules, but can not remove an empty library from an ODB file. This is not limited to only the standard library, but any library. The same is not true when I tried it with an ODT file, including with the ODT file the ability to remove the Standard library by first removing all modules, which seems to automatically remove the library now on save. (I don't remember that from earlier versions?)

Two things though - first time I tried to remove the last module, Standard->module1 it was not actually removed and was there when I re-opened the file. On a second try I was able to remove it permanently.

Anyway - I'll put some time to this tonight and test on older builds to find where the regression takes place.
Comment 6 Julien Nabet 2011-11-26 14:35:14 UTC
Created attachment 53872 [details]
The file without the module

I reproduced the pb on 3.4.4 but not on master. I attached the file without the module containing the 2 macros.
On 3.4.4, I've seen no specific error messages on console but had several exceptions launched.
Comment 7 Björn Michaelsen 2011-12-23 12:29:19 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 8 Björn Michaelsen 2011-12-23 17:02:28 UTC
needinfo keyword redundant by needinfo status.
Comment 9 Robert Großkopf 2012-10-10 07:48:08 UTC
I don't have any problems to delete the Basic-module.
Could be a good idea to delete the entry-folder "standard", too. Then there is no asking for macros any more, when I have deleted all the macros and modules. But this is also reported in comment 5, not the behavior this bug-report is written for.

Could anybody else confirm the behavior, that modules could not be deleted?
Comment 10 Andreas Säger 2012-10-10 12:03:33 UTC
Tested once more with LibreOffice (Ubuntu ppa) and with 3.5.6 on Windows 7.

Create new database (any type, any content or none).
Tools>Macros>Organize>Basic..., select the new database, hit button [New] which adds a new Basic module with an empty Main routine default content.
Save, close, reopen, get a macro warning.

Tools>Macros>Organize>Basic..., button [Organizer...], tab Modules, select the new module and hit [Delete], close dialogs, save, close, reopen, get macro warning, Tools>Macros>Organize>Basic... 
The Basic module is still there.

For what it's worth: My preferred office suite --which is AOO 3.4.1 by now-- shows a macro warning but the module is hidden from the GUI.

I can remove the embedded Basic trash from the document archive.
Comment 11 Robert Großkopf 2012-10-10 19:01:28 UTC
Created attachment 68417 [details]
Shows the empty folder "Standard" with no module

Can't confirm this behavior with any LO-Version here. Last test I made with LO The attachment shows the empty folder. It also shows the last opened module. In this example it's the module "Currency" from "LibreOffice Macros".
The Macro-warning appears when the folder "Standard" exists. This folder could be empty or not. I opened the packed *.odb-file. When you delete the folder "Basic" the warning will be gone - as Andreas confirmed.
Comment 12 Julien Nabet 2014-07-23 20:38:12 UTC
Just for the record, I can still reproduce this on pc Debian x86-64 with master sources (future 4.4.0) updated yesterday.
Comment 13 Andreas Säger 2014-07-23 22:30:51 UTC
This complete lack of competence together with automated [NEEDINFO] messages for 6 of my issues that could not be confirmed due to a lack of competence was the reason why I quit supporting LibreOffice.

Here we go again with LO 3.5 (the one from Ubuntu 12.4 is the only one I still have at hand):
1) File>New>Database ... [any settings, any connection or new database]...
In the following steps I assume a file name MyDB.odb
2a) Tools>Macros>Organize>Basic...
2b) select the new database document MyDB.odb (_not_ "LibreOffice" nor "My Macros")
2c) Click the new button, confirm the defaults, save the document and close the document.
Document MyDB.odb has a librariy named "Standard" with a module named "Module1" containing an blank macro skeleton named "Main". 
3) Save the document, close the document.
4) Reload the document and notice the macro warning (unless you saved MyDB.odb in a trusted directory).
5a) Tools>Macros>Organize>Basic...[Organize...], tab "Modules". 
5b) Select the document MyDB.odb, the library "Standard" therein and its "Module1"
5c) click the "Delete" button and confirm deletion
The module disappears from the macro organizer.
6) Close the organizer, save the document, close the document.
7) Reload the document and notice the macro warning (unless you saved in a trusted directory).
8) Tools>Macros>Organize>Basic...[Organize...], tab "Modules", MyDB.odb->Standard->Module1
Yes, the module we deleted is still there.
Comment 14 Julien Nabet 2014-07-24 04:09:09 UTC
Andreas: have I said the contrary on my comment? I just indicated that the problem is still there. No need to tell me the whole process to reproduce the problem.

Lionel: any idea here?
Comment 15 Lionel Elie Mamane 2014-07-24 05:30:28 UTC
Can't reproduce exactly as described, not with LibreOffice and not with LibreOffice

When I delete the module (named by default "Module1"), the module stays deleted. However, the "Standard" *library* stays, and is not deletable. Automatically dropping an empty "Standard" library (which has *neither* Basic modules *nor* Dialogs) could be an idea...

Julien: if you want to take a stab at it, I'd look around SfxLibraryContainer::storeLibraries_Impl in basic/source/uno/namecont.cxx
or maybe its caller on save (the function that calls it).

Actually, it tries to do that:

     if ( bStorage )
         // Don't write if only empty standard lib exists
         if ( ( nNameCount == 1 ) && ( aNames[0] == "Standard" ) )
             Any aLibAny = maNameContainer.getByName( aNames[0] );
             Reference< XNameAccess > xNameAccess;
             aLibAny >>= xNameAccess;
             if ( ! ( xNameAccess->hasElements() || ( bInplaceStorage && isModified() ) ) )

Need to debug what goes wrong there... Which part of the if-condition makes that fail?
Comment 16 Julien Nabet 2014-07-24 05:44:46 UTC
Lionel: in my case Module1 stays :-( So obviously "xNameAccess->hasElements()" is true
Comment 17 Julien Nabet 2014-07-24 05:59:09 UTC
Sorry for the confusion, I got only "Standard" without module, if I use "Tools/Macros/Organize Dialogs (+ "Module" tab)" and not "Tools/Macros/Organize Macros/LibreOfficeDev Basic"
So after having removed the Module, the breakpoint in basic/source/uno/namecont.cxx shows that we don't return line 1842 because bInplaceStorage and isModified() are both true. (xNameAccess->hasElements() is false)
Comment 18 Lionel Elie Mamane 2014-07-24 07:06:54 UTC
OK, this looks like exactly the same as bug 52076 (which already has a related commit), so centralising there.

*** This bug has been marked as a duplicate of bug 52076 ***