@tobiaskrais:
Please
- specify your Platform and OS
- attach a test kit with sample documents, integrated macros ...

@rainerbielefeld: Wow, this was fast!
1. All OS. I tested on WinXP and Ubuntu 8.10 with the OpenOffice.org
installation packages.
2. The sample code can be found here:
http://codesnippets.services.openoffice.org/Office/Office.OpenDocumentFromURL.snip

If you need further information, please ask me.

as->tobias:

Please specify which API calls you used for ...
a) open documents
b) closing documents.
c) Or if you closed such documents manually (mouse click inside UI).

For me it doesnt look like an issue. It looks like you used the wrong set of APIs.
First you should define if you wish to use same "document behaviour" as OOo it
has by default. If the answer is yes you cant use (!) API's like
loadComponentFromURL () or XCloseable.close(). You have to use XDispatch API only !

If you wish to implement your own behaviour ... you must intercept commands like
.uno:CloseDoc/CloseFrame/CloseWin .-.. but you can use loadComponentFromURL() or
XCloseable.close(). Otherwhise "magic" regarding OOo shutdown will disturb your
use case as you described it already. On ther other side ... then you are
responsible to make sure the office will shutdown ... at least in case last
document was closed. Because in such API-use-case it's your job doing that .-)

as->tm: Seems to be my area .-)

tobiaskrais -> as: Here my answers to your questions:

a) as I wrote to Rainer, I use the following API calls to open a document:
http://codesnippets.services.openoffice.org/Office/Office.OpenDocumentFromURL.snip
(I created the snippet, its exactly my code).

c) For closing I use the UI.

You further explanations are very interesting. I still think it's an issue,
although not a serious one, may be only a very rare use case. One question: may
a OpenOffice.org frame close other frames with documents? I think no. In any case.

as->tobias:

It's not a bug ... it's how OOo reacts for different user requests. Some user
wish to have stay OOo in memory after last document was closed ... some other
ones wish that OOo shuts down automaticaly if last visible document was closed.

So the following should happen:

a) If you close the last visible frame ... OOo shuts down.
b) If you close the last open document ... but had two views to the same
document ... both views will be closed (means two frames will be closed!) ...
and OOo shuts down.
c) If you close the last document or frame ... but furthermore a help window was
open ... OOo shuts down ... because help was not classified to be a reason not
to shut down .-)

So you see ... closing one frame WILL close other frames if there constellation
was the right one.

The real problem of your issue I can see ... you said:
"1. Open a document (e.g. an odt file) via API and then close the
document (only the document, not the OOo frame). Thus an empty OOo frame
remains (in OOo3 the OOo app chooser is loaded in the frame)."

I cant reproduce that with an actual OOo version. At least not using the UI to
close the document. Such state can be reached only in case API's are used.
Anyway: if such state would be reached it's a bug. An empty frame never should
stay alive. At least our StartModule (you name it App Chooser) should be loaded
into that last open frame.

If you bring the office in such state (empty frame) it's detected as
"superflous" and last REAL document frame will close such superflous frames too.
So I dont see any issue here ... excepting the mentioned "empty frame" ... which
cant be reproduced by me.

tobiaskrais -> as: OK. I don't reach a superflous frame. Now I understand
better. I set the issue to invalid.

invalid -> closed