Apache OpenOffice (AOO) Bugzilla – Issue 76129
Impossible to bind a macro to an event of a FORM or REPORT inside an OpenOffice.org Base
Last modified: 2009-07-20 15:22:17 UTC
It is imposible to BIND a macro to an EVENT of a FORM inside an OpenOffice.org Base document (ODB). If we open a FORM inside an ODB, go to the menu "TOOLS" - "CUSTOMIZE", and we choose the tab "EVENTS", in the "Save in" list box there is NO chance to choose the current open form document (which is really an ODT), just OpenOffice.org as a whole. Therefore, the user can't assign a macro to an event (what is called "event binding") using this dialog. He/she can bind an event using an OOoBasic macro, because the FORM document suports the interface com.sun.star.document.XEventsSupplier that has a method getEvents() to bind events to the com.sun.star.document.OfficeDocument; but the user can't use the GUI to do this, as he can with other Writer (ODT) documents.
*** Issue 76131 has been marked as a duplicate of this issue. ***
configming, grabbing, targeting
Hmm, this is more difficult than I thought. I have a patch which enables the respective tab page. Unfortunately, there's a lot of strange code involved which uses the infamous SfxDocShell::GetFoo methods, which do not work together with database documents (and embedded forms). As a result, the Macro Selector dialog, which opens when you press the "Macro" button on the "Events" page, does not contain the form document's macros. Sigh. This code is a piece of ... ehm, well ...
Created attachment 47088 [details] first steps of a patch
The attachment contains first steps towards a patch. I started developing this in CWS dba23b (so the patch is relative to this CWS), but found that there's much more components (ScriptProvider, e.g.) which stupidly use SfxObjectShell and friends, instead of clean UNO methods. The patch fixes the UI to allow to select the embedded documents as event source, but when browsing for the macro to bind to an event, this dialog will not list the embedded documents. IoW: more work to be done.
resetting STARTED state - do not work at this anymore ATM.
fs->kso: please take over the remaining part (in CWS basmgr03): With the patch above (already committed and built), the behavior now is as follows: - start OOo - open a database document - open a form embedded in this database document - select menu: Tools / Customize - select tab page: Events - press button: Macro => the macro selector is opened, but the form does *not* appear in the list - close the dialogs - close the form - re-open the form - Tools / Customize / Events / Macro => the macro selector is opened, this time the form *does* appear in the list The reason for this is in the tdoc UCP, more precise, in OfficeDocumentsManager::isOfficeDocument: There, a check is made whether the frame of the current controller of the document is "on top" - if not, it's assumed the document is no office document. Now when the document manager is created while the form already is open, then isTop returns false, thus the form is assumed to be no office document. Now when the form is opened while the document manager is already alive, the isTop check still returns true - it only becomes false later when the frame gets a new parent frame. (In fact, the definition for isTop is "the frame has no parent, or the parent is the desktop".) All in all, I think the isOfficeDocument method is wrong here. I could imagine the following alternative solutions: - use supportsService( "com.sun.star.document.OfficeDocument" ) instead. Finally, it might make sense to simply believe what the document is telling about itself. - use XFrame.getContainerWindow, to determine whether it supports the XTopWindow interface. (Though, comments in AS' code in the framework module suggest this might not be reliable. Perhaps AS - on cc - has an opinion here.) - convince AS to adjust XFrame::isTop to the new realities :) Which means: The fact that top level frames can have parent frames has been introduced with the changes in CWS fwkdbdesign01, and is pretty new. Maybe XFrame::isTop simply doesn't care for this new concept, yet. fs->as: In recent code in framework, there's a WindowHelper::isTopWindow method which encapsulates the question whether a window really is a top window. Perhaps Frame::isTop should use isTopWindow instead?
> please take over the remaining part (in CWS basmgr03): this one was too optimistic ... there's more to do, since there are dozens of assertions from SFX if you actually try to assign a macro to an event of the form. However, this will be my part, again(at least to find out).
fs: As discussed... your task again.
implemented in CWS basmgr03
note that when you actually bind a macro to any of the events, then in a non-product builds, you will be slain by dozens of assertions. This, however, is also the case for "normal" text (and other) documents, which now is issue 81004.
fs-> msc: please verify in CWS basmgr03
verified in cws basmgr03
Specific issue passes test on XP SERIOUS SECURITY ISSUE See Issue#52527
My security test was INVALID - I had used a library function Retested with a macro embedded in the embedded form. The security settings behavior is unchanged from Issue#52527 the embedded macro is not allowed to run with the setting to Very high. With setting of Medium the embedded macro is reported and the user must authorize even if in the trusted path. Sorry for my jumping the gun on the warning.
Thanks for clarify this. The fix is targeted for OOo 2.x but it's still unable to bind a macro in Base 3.0.
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues