Issue 80769

Created attachment 47581 [details]
Bugdoc with macro

ab->as: According to gh -enableautomation is only used for low level things like 
different window manager handling for testtool. So the connection to macro
import is unclear. Anyway this is done in the framework. Please have a look.

cc'ing mba

Frank, this is a problem with the basic code you added to binfilter. If any
non-binfilter document has been created before  the binfilter basic module is
dysfunctional. ("-enableautomation" errornouosly always creates an empty Writer
doc and so triggers the bug.)

The following code in binfilter/bf_basic/source/basmgr/basmgr.cxx:

BOOL BasicManager::HasBasicWithModules( const SotStorage& rStorage, const
String& rBaseURL )
{
	if( !rStorage.IsStream( ManagerStreamName ) )
        return FALSE;

    StarBASIC* pDummyParentBasic = new StarBASIC();
    BasicManager* pBasMgr = new BasicManager( (SotStorage&)rStorage, rBaseURL,
pDummyParentBasic );
    BOOL bRet = FALSE;

	USHORT nLibs = pBasMgr->GetLibCount();
	for( USHORT nL = 0; nL < nLibs; nL++ )
	{
		BasicLibInfo* pInfo = pBasMgr->pLibs->GetObject( nL );
		StarBASIC* pLib = pInfo->GetLib();
		if( !pLib )
        {
            BOOL bLoaded = pBasMgr->ImpLoadLibary( pInfo, NULL, FALSE );
            if( bLoaded )
                pLib = pInfo->GetLib();
        }
		if( pLib )
        {
	        SbxArray* pModules = pLib->GetModules();
            if( pModules->Count() ) // ***
            {
                bRet = TRUE;
                break;
            }
        }
    }

    delete pBasMgr;
    return bRet;
}

always returns "FALSE" in the marked code line when the bug is triggered. This
is different if the binary document is the first to be loaded.

This reminds me of a problem with SHL_PTR in Basic but AFAIR it was fixed by
Carsten. So it seems that there is another global variable that is shared
between binfilter's basic and the "other one".

In result basic from binary files is always lost as soon as the first non-binary
file was loaded. I have no idea if this is a showstopper but surely it's a
regression.

I found binfilter/bf_basic/source/sbx/sbxbase.cxx:

SbxAppData* GetSbxData_Impl()
{
#ifndef DOS
	SbxAppData** ppData = (SbxAppData**) ::GetAppData( SHL_SBX );
	SbxAppData* p = *ppData;
	if( !p )
		p = *ppData  = new SbxAppData;
	return p;
#else
	SbxAppData** ppData;
	SbxAppData* p;
	p = *ppData  = new SbxAppData;
	return p;
#endif
}

That looks as if the "SHL_PTR" bug is not or only partially fixed.

This is the killer - together with another bug:

StarBASIC::StarBASIC( StarBASIC* p )
	: SbxObject( String( RTL_CONSTASCII_USTRINGPARAM("StarBASIC") ) )
{
	SetParent( p );
	pLibInfo = NULL;
	bNoRtl = bBreak = FALSE;
	pModules = new SbxArray;

	if( !GetSbData()->nInst++ ) // ***
	{
		pSBFAC = new SbiFactory;
		AddFactory( pSBFAC );
		pUNOFAC = new SbUnoFactory;
		AddFactory( pUNOFAC );
		pTYPEFAC = new SbTypeFactory;
		AddFactory( pTYPEFAC );
		pCLASSFAC = new SbClassFactory;
		AddFactory( pCLASSFAC );
		pOLEFAC = new SbOLEFactory;
		AddFactory( pOLEFAC );
	}
//	pRtl = new SbiStdObject( String( RTL_CONSTASCII_USTRINGPARAM(RTLNAME) ), this );
	// Suche ueber StarBASIC ist immer global
	SetFlag( SBX_GBLSEARCH );
}

The marked line is an object that is shared between binfilter and "the other
code". So as soon as the first "sb" instance is created elsewhere binfilter
refuses to instantiate its own SbxFactories. So even fixing the first problem
(replacing SHL_PTR by a static pointer) is not enough. We need an own instance
counter for binfilter:

SbiGlobals* GetSbData()
{
	SbiGlobals** pp = (SbiGlobals**) ::GetAppData( SHL_SBC );
	SbiGlobals* p = *pp;
	if( !p )
		p = *pp = new SbiGlobals;
	return p;
}

is the culprit - again a SHL_PTR problem. 

grepping for "SHL_" in bf_basic showed me more of them. :-(
So I'm afraid that this will take some more work to do.

I was too pessimistic. :-)
All occurrences where either includes or code that was commented out. :-)

So fixing the quoted methods is enough. Frank, please comment.

Oliver, what about the target?

Excellent analysis, I'd say. Going to attach a patch.

Oliver, this patch can go into any version you like ... I'd fix this for 2.4,
but if you need it earlier, tell me. (Though, the bug exists for quite a while
now, and has never been noticed so far, so I assume it isn't that urgent.)

Created attachment 47694 [details]
sugegsted patch

Thanks, Frank.

Oliver, as Frank pointed out this issue is not new but IIRC it was not present
in 2.2.x so it is a regression.
In case Christian Guenther didn't complain we could add the patch to the CWS
binfilterregression though it is already "ready for QA". Perhaps you can
negotiate with Christian.

adjusting prio and target 2.3

fix committed in CWS bfbasic

fs-> oc: please verify in CWS bfbasic

verified in internal build cws_bfbasic

closed because fix available in builds OOH680_m7 (OOo 2.4) and SRC680_m245 (OOo 3.0)