Created attachment 51233 [details]
Bug doc with form

I can reproduce this in OOH680m5, but not in OOH680m4 - Andrew, can you confirm
that you use m5?

Ah, I just noticed that in users@dba, Juri and you talk about m5 - so I assume
you're in fact using this version. Strange enough, according to EIS, nothing has
been integrated into this MWS which I would assume could cause this.

adding keyword "regression", since it works fine in m4

Uhoh. Pretty much sounds like a regression of issue 84941, titled "Allow macro
execution for OOo documents embedded in OLE server." Technically, forms are
embedded documents, and this is what has been tampered with ...

investigating

I suppose you don't really need this, but since you asked.

Yes, the problem is only with 680M5, downloaded from the main website today.

Thanks for confirming, Drew

fs->mav: That's a regression of your fix for issue 84941, I'd say.

Before your changes, the macro execution mode was held in
DocumentMacroMode_Data::nMacroExecutionMode, and initialized exactly once. Your
change was to keep the mode in only one place, by introducing the
"setImposedMacroExecMode" method. Which is a Good Thing, so far.

What happens is something along those lines:
- the form is loaded
- during/after loading, the DocumentMacroMode::adjustMacroMode. It calculates
  the effective macro exec mode to be ALWAYS_EXECUTE_NO_WARN, which is correct,
  since the form itself does not contain any macros.
- This mode is forwarded to the document, using the newly introduced
  setImposedMacroExecMode method. This results in the proper SID_MACROEXECMODE
  item being put into the object shell's medium's item set.
- Now when we put the state of the embedded object to ACTIVE, then with the
  following stack:
    framework::LoadEnv::initializeLoading(...)
    framework::LoadEnv::loadComponentFromURL(...)
    framework::Frame::loadComponentFromURL(...)
    DocumentHolder::LoadDocToFrame(unsigned char bInPlace='Ü')
    DocumentHolder::GetDocFrame()
    DocumentHolder::Show()
    OCommonEmbeddedObject::SwitchStateTo_Impl(long nNextState=2)
    OCommonEmbeddedObject::changeState(long nNewState=2)
  , the macro mode is reset to NEVER_EXECUTE.
  Consider framework/source/loadenv/loadenv.cxx, lines 479ff, and lines 496f

From this time onwards, any call to the object shell's getImposedMacroExecMode
will return NEVER_EXECUTE.

Note that there has not been any change in the load environment between m4 and
m5. That is, the framework always passed a NEVER_EXECUTE at this point. However,
this never hit us, since the macro exec mode was cached in
DocumentMacroMode_Data::nMacroExecutionMode, as said above.

I am not sure what is the actual bug reason here - perhaps
DocumentHolder::LoadDocToFrame should pass the current MacroExecMode of the
document to the new loading call. More precise, it should probably obtain the
current model args (XModel::getArgs), perhaps filter them, and then pass them to
the loadComponentFromURL call, to ensure they're preserved.

Another option might be to fix the initializeLoading implementation: Finally, we
currently load an existing document into a frame (that is, the Model argument in
the media descriptor exists - the document is actually loaded, but not put into
a frame, yet). Why would initializeLoading want to overrule the arguments which
do already exist at the model?
Thinking more about it, I'd say this is the real bug: the load environment
should *not* tamper with the media descriptor if there is a Model argument, i.e.
the document is already loaded, and only to be plugged into a frame.
fs->as: What's your opinion on this (see my previous comment for a more
extensive error analysis)?

as->fs: Seams you are right. Loadenv shouldnt ignore such model arguments.

as->mav: Please try the attached file if it can fix the problem. It looks for a
might existing model, merge its arguments with the outside set of arguments ...
but then it does the same then before - making sure that some important
properties will be set if they dont was set already from outside or by the model.

Created attachment 51246 [details]
contains the patch

From my point of view the loadComponentFromURL() should not ignore all the
provided in the MediaDescriptor arguments from my point of view. Attaching of a
model to the frame changes status of the model, so the model might need changes
in the MediaDescriptor. So it looks for me quite reasonable to use the
MediaDescriptor from the loadComponentFromURL() and merge it into the document
MediaDescriptor.

I would say, in this case the loadComponentFromURL() just should not add the
default values for MediaDescriptor in case of loading of a model to a frame.

The patch from AS has been integrated into fwk85.

Please verify the issue.

verified in CWS fwk85

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=OOH680%2Ffwk85

Tested this with RC1 680m7(Build:9272) under XP - it still fails.

cannot confirm - works perfectly for me with exactly this version: 2.4 RC1
680m7(Build:9272) under XP.

You did not, by chance, forget to copy the macro to the global Basic libs? This
was what fooled me in the first place ...

I made sure that I actually had the macro in the standard library.

Under XP there was some additional information I should of added - if I open a
Writer file that has data controls on it and these call a macro this works,
always. In fact if I did this and then opened the database and the embedded
form, the call on the embedded form worked.

I then completely exited OO.o ( including quickstarter ) - Now opened the Base
file first, then the embedded form - the call does not happen - UNTIL I open the
Writer and execute a call to a macro one time - then the embedded form will work
again.

( That was from memory as I am under Linux right now )

New information

Using Kubuntu 7.1 x86_64, OO.o x86_64, 680m7(Build:9272) downloaded from Linux
CZ it does not just not work - using the attached bug doc database, copied the
code into standard library.

Changing a record on the form crashes the application immediately. (
unfortunately Pavel's builds do not trigger a crash report it seems ) 

cannot confirm with Vanilla OOo build (2.4 RC1) on some SuSE 9.2. Going to try
linux.cz's OOHm7 build.

fs->atjensen: While looking into another issue of yours, I noticedyou're using
64 bit versions. Perhaps that makes a difference. Care to try a 32 bit version?

cannot reproduce with linux.cz's build, either.

Tested w/ Kubuntu 7.1 32bit, RC1 - passed.

Reinstalled RC1 under Windows XP and ran again - passed.

Closing