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.
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 ?
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.
(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
> 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 :-)
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.
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.
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.
[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
needinfo keyword redundant by needinfo status.
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?
Tested once more with LibreOffice 188.8.131.52 (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.
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 184.108.40.206 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.
Just for the record, I can still reproduce this on pc Debian x86-64 with master sources (future 4.4.0) updated yesterday.
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
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.
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?
Can't reproduce exactly as described, not with LibreOffice 220.127.116.11 and not with LibreOffice 18.104.22.168.
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 == "Standard" ) )
Any aLibAny = maNameContainer.getByName( aNames );
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?
Lionel: in my case Module1 stays :-( So obviously "xNameAccess->hasElements()" is true
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)
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 ***