Macros in Database Documents

From Apache OpenOffice Wiki
Jump to: navigation, search
Specification Status
Author Frank Schönheit
Last Change 2008-09-09
Status (Help) Standard

Abstract

OpenOffice.org Base, unlike the other OpenOffice.org applications, is currently not able to embed macros and scripts into its documents. We will empower Base users to use macros and scripts (StarBasic, JavaScript, BeanShell, Python) in their database documents the very same way they can use them in all other application's documents.

Detailed Specification

Accessing Macros and Scripts

  • Macro and Script Organizers (Tools / Macros / Organize / *) will show opened database documents, and allow editing/creating macros/scripts therein.
  • The Basic IDE will treat macros in database documents the very same way as macros in other application's documents.
  • The Macro Selector (Tools / Macros / Run...) will show the current database documents, and allow to run them, when invoked for this document, or any of its descendant documents.
  • The UI customization dialog (Tools / Customize ...) will allow access to the current database document's macros and scripts, when invoked for this document, or any of its descendant documents.

Database Document Macros vs. Macros in Sub Documents

Up to now, macros can be embedded into sub documents of a database document, that is, into forms and reports (which technically are Text documents).

We will not allow this in the future anymore. The reason is that it is hard to find a consistent concept (in particular: create a consistent user experience) which allows both, macros in the embedding database document and macros in the embedded form/report document.

As a consequence, in any place where you can currently access macros in forms, you won't be able to do so anymore. Instead, you can access the database document's macros.

This means:

  • Currently, when you have a form, and open the customization dialog, it will give you access to macros embedded in this form. In the future, you will have access to the database document's macros only.
  • Currently, you see all open form documents in the macro organizer and the macro selector. In the future, you will see open database documents only (and all other application's documents, of course).
  • Assigning macros to elements in a form document (in particular: to events of form controls, from the "Events" tab page of the property browser) will be possible with macros from the database document only, not with macros from the form document.
  • You will be able to run any macro/script which is embedded in a database document from either the document itself, or any of its sub components: forms, reports, table design, query design, relation design, table data view.
  • You will be able to customize any such macro/script into a toolbar, or a menu, of any sub component.
  • When recording a macro in a form or report, the final dialog which lets you decide where to store the macro will not list the form/report anymore, but the database document.

Changes to Script Languages

Global Variables in Basic Macros

Current Situation
  • Macros located in documents can only be called from within the very same document. This might happen through document items bound to macros (command buttons, fields in Writer, shapes in Impress, and the like), or through macros customized to appear in the the document's, or the document classes, UI.
  • The only exception is the Basic IDE, which allows to run macros from arbitrary documents.
  • When running a macro located in a document, there is a global variable called ThisComponent, which refers to the document.
  • When running a macro located in the application's or user's basic libraries, then there's also a variable called ThisComponent, which refers to the active document.
  • Database documents do not participate in the "global" ThisComponent: When you, from within a database document, run a Basic macro located in the application's or user's Basic libraries, then ThisComponent will refer to the single document that was last active before the database document became active.
Changes with Macros in Database Documents

In general, the change described herein for the first time allows to, from within a document, execute macros which are not located in this very document, but in another one. Specifically, from within a form or report (which technically, and probably perceived by many users, are separate documents, though semantically only "sub components" of the database document), you can execute macros located in the database document.

This implies we need to separate the two aspects of ThisComponent which so far are used equivalently: By now, ThisComponent refers to the document from which the macro was invoked, and at the very same time to the document in which the macro was located. Both are actually the same.

With macros in database documents, that becomes different: Users shall be able to execute, in a form document, macros which are located in the database document. Even more, users shall be able to execute such macros in other sub components of a database document, such as the query designer. Those sub components usually don't even have a XModel associated with them.

We will do this separation by introducing another global variable, called ThisDatabaseDocument. This variable will be available in Basic macros which are embedded into a database document, and always refer to this very document.

Hint.png
See the discussion page of this article for a discussion on this new variable

ThisComponent, in turn, will always be the component which was active when the macro was invoked. This holds no matter whether the macro is located in the database document's or in the application's Basic library. Also, it holds no matter whether the active component is a database document or any of its sub components. In particular, the various designers are also available as ThisComponent.

Script Contexts in other Script Languages

In other script languages, there is no strict equivalent of Basic's ThisComponent. Instead, scripts in other languages get an instance of XScriptContext passed, which has an method getDocument, to "obtain the document reference on which the script can operate".

Such scripts also need to distinguish between the component for which they were invoked, and the document in which they're actually embedded (if any).

This is done by introducing a member XScriptContext::getInvocationContext. It will refer to the component from which the script was invoked, being either a document (i.e. supporting XModel) or a controller (i.e. supported XController).

XScriptContext::getDocument will continue to refer to the document in which the running script is embedded (if any), so if a script is invoked from within the document in which it is embedded, then XScriptContext::getInvocationContext will equal XScriptContext::getDocument.

Migration

Database documents created with version prior to OpenOffice.org 3.0 might contain forms or reports with embedded macros or scripts. Since this constellation is prohibited as soon as macros in database documents are implemented, a migration path is necessary.

The goal is to transform documents so that all the macros and scripts are in the database document, not in its sub documents anymore. Unfortunately, this cannot be done automatically.

For once, it is difficult to (in a generic way) merge all macros from embedded documents into the database document. For instance, if two forms both contain a Basic library named "Standard", with a module named "Module1", with a function named "Foo", then moving both libraries/modules into the database document's Basic libraries will lead to name clashes. Solving those in an automated way is possible, but references to those macros will almost certainly be broken then.

Second, a complete automatic migration requires a syntactical analysis of the macro/script code. For instance, imagine a Basic macro which does a LoadLibrary call with the name of a Basic library in the form document. If this library has been moved to the database document, and perhaps been renamed in this course, the LoadLibrary call would need to be adjusted to refer to the new name. This is effectively impossible without analyzing the Basic code, effectively compiling it. Similar arguments hold for other script types.

As a consequence, we won't migrate macros and scripts in sub documents automatically.

Compatibility Warning

Instead, we will show the following message box when the user opens a database document which contains a form or report with embedded scripts or macros:

Macros in Database Documents: Compatibility warning

User Interface Elements

Type Property Value Comment
Label Text The document contains forms or reports with embedded macros.
Label Text Macros should be embedded into the database document itself.

You can continue to use your document as before, however, you are encouraged to migrate macros. The menu item "Tools / Migrate Macros ..." will assist you with this.

Note that you won't be able to embed macros into the database document itself until this migration is done.

So, when the user simply opens an "old" document containing macros and/or scripts in the sub documents, nothing except the above warning will happen in the first instance. Until the user migrated the macros, the database document, and all sub documents, will behave as if the feature which this spec is about were never implemented. In particular, the user is free to create additional or modify existing macros in her forms and reports, to customize macros from sub documents into her toolbar/menu, to bind those macros to events in the sub documents, and so on.

Migration Wizard

We will introduce a new menu item, called "Migrate Macros ...", located in the top-level menu "Tools", immediately below the existing "SQL ..." item.

Menu Item(s)

Item Sub Item Sub Item KBD Shortcut Icon Comment
Migrate Macros ...

The menu item is available only if any of the database document's sub documents contains scripts or macros, and if the document is not opened read-only.

When the user selects this menu item, a wizard will guide her through the migration, which effectively consists of the following steps:

  1. close all sub components of the database document, namely forms, reports, and any open designers
  2. backup the database document
  3. migrate the scripts and macros while displaying a progress bar
  4. show a summary
Preparation

The first step of the wizard looks as follows:

Migration Wizard : Step 1
  • page contains explanatory text only
  • 'Finish' button is disabled
  • in the roadmap, steps "3. Migrate" and "4. Summary" are disabled
  • when leaving the page by pressing 'Next' or clicking another step in the wizard's roadmap, all sub documents of the database document are closed
  • when closing the sub documents is not successful, e.g. because the user vetoes closing a modified sub document, the wizard will stay open, but not advance to another page

User Interface Elements

Type Property Value Comment
Label Text Welcome to the Database Macro Migration Wizard
Label Text This wizard will guide you through the task of migrating your macros.

After you finished it, all macros which were formerly embedded into the forms and reports of the current database document will have been moved to the document itself. In this course, libraries will be renamed as needed.

If your forms and reports contain references to those macros, they will be adjusted, where possible.

Before the migration can start, all forms, reports, queries and tables belonging to the document must be closed. Press 'Next' to do so.

Backup
Migration Wizard : Step 2
  • allows user to choose a location/name to backup her document to
  • input field for backup location:
    • is the usual auto-completion input field, as known from e.g. the internal File-Open-dialog and the "Load URL" box in the standard toolbar
    • will be pre-filled with a location/name which is the database document's location/name, with an additional part ".backup" before the extension
  • 'Browse' button:
    • will open a file picker, effectively a "Save As" dialog
    • closing this dialog with OK will fill in the chosen file name into the input field
    • selecting an existing file in this dialog will ask the user whether to overwrite this file (as in a usual Save-as-dialog), when the dialog is to be closed with OK
  • explanatory text at the bottom of the wizard is visible if and only if the backup location input field will contain text
  • manually entering a file name in the input field, or keeping the pre-filled name, and advancing to the next wizard step (by either means) will
    • check whether a file at the given location already exists
    • if so, ask the user whether to overwrite the file.
    • The query box for this is the very same as used for the same purpose in the Save-as-dialog
  • wizard logic:
    • 'Finish' button is disabled
    • in the roadmap, steps "4. Summary" is disabled
  • upon pressing 'Next', or clicking onto "3. Migration" in the roadmap
    • the document is saved to to the chosen location
    • if the backup fails, the message of the error which happened will be shown - the same which would be shown when the user would have initiated a normal File/Save As operation

User Interface Elements

Type Property Value Comment
Label Text Backup your Document
Label Text To allow you to go back to the state before the migration, the database document will be backed up to a location of your choice. Every change done by the wizard will be made to the original document, the backup will stay untouched.
Label Text Save To:
Button Text Browse ...
Label Text Press 'Next' to save a copy of your document, and to begin the migration.
Error Conditions

If the backup location as entered by the user denotes the location of the database document itself (i.e. the user attempts to backup the document to itself), the below error message is shown when the user attempts to proceed, the focus is put into the "Save To" field, and the wizard does not advance.

Migration Wizard : Error message for an illegal backup location
Migrate
Migration Wizard, Step 3: Migrate
  • migration will start as soon as the page is entered
  • for every form/report:
    • the document be loaded (hidden from the user)
    • the macro, script and dialog libraries in the document will be moved to the database document, and renamed by prefixing the library name with
      • "Form_" respectively "Report_"
      • the name of the form/report itself, with an appended _
      • example: In a form named "customers", the library "Standard" would be renamed to "Form_customers_Standard"
    • linked libraries will be preserved as linked libraries
    • read-only libraries will continue to be read-only after the migration/renaming
    • password protected libraries will trigger a prompt to the user to enter the password, using the same dialog as known from the Basic organizer when accessing password-protected libraries
    • references to macros/scripts in this library will be adjusted if and only if:
      • the user bound such a macro/script to an event of any form or form control, i.e. it appears on the "Events" tab page of the property browser when inspecting the form/control
      • the user bound such a macro/script to any of the document-wide events, i.e.it appears on the "Events" tab page of the customization dialog
    • the document will be stored
  • 'Current object' contains the name of the form or report which is currently being processed
  • 'Current action' is either one of
    • the text which would appear in the status bar when the form/report would be normally loaded non-hidden
    • "migrating libraries ..." when the macro, script and dialog libraries are being migrated
  • 'Current progress' shows the progress of the current action.
  • 'Overall progress' shows the relative number of processed documents, both as number and as progress bar
  • the explanatory text at the bottom of the page
    • is initially hidden
    • will appear when the migration was finished
  • wizard logic:
    • 'Back', 'Next', 'Finish', 'Cancel' buttons are initially disabled
    • in the roadmap, all steps except the current one are initially disabled
    • 'Next', 'Finish' will be enabled as soon as the migration was finished
    • in the roadmap, '4. Summary' will be enabled as soon as the migration was finished

User Interface Elements

Type Property Value Comment
Label Text Migration Progress
Label Text The database document contains $forms$ form(s) and $reports$ report(s), which are currently being processed: $forms$ and $reports$ will be replaced by actual numbers at runtime
Label Text Current object:
Label Text Form '$name$' This refers to a form document inside a database document.
Label Text Report '$name$' This refers to a report document inside a database document.
Label Text migrating libraries ...
Label Text Current progress:
Label Text Overall progress:
Label Text document $current$ of $overall$ $current$ and $overall$ will be replaced by actual numbers at runtime
Label Text All forms and reports have been successfully processed. Press 'Next' to show a detailed summary.
Error Handling during Migration
  • Whenever an unrecoverable error occurs during the migration
    • the complete process will be canceled
    • the wizard will automatically leave the "Migration" page, and advance to the Summary page
    • on the summary page, the error which happened will be described (see below)
    • the error description is a human-readable short text of the error type
    • the "Finish" button of the wizard will be permanently disabled, and the "Cancel" button will be enabled, this way indicting the migration process cannot be finished anymore
    • if the error was induced by an exception caught when calling into foreign code, the information about this exception - type and message - will also be shown
  • Whenever a recoverable error occurs (see below for a list of errors, and a note which ones are recoverable), the migration process will be continued.
  • when the dialog is closed after an unsuccessful migration, the document will automatically be reloaded from its backup

The following error conditions are recognized and distinguished by the migration process:

Condition Error Text Comment
loading a form/report (hidden) failed opening '#name#' failed
  • #name# will be replaced with the description of the actual sub document, either "Form" followed by the hierarchical form name, or "Report" followed by the hierarchical report name
  • this error condition can usually only be met for corrupt database documents
closing a form after having migrated its scripts and macros failed closing '#name#' failed
  • #name# will be replaced with the description of the actual sub document, either "Form" followed by the hierarchical form name, or "Report" followed by the hierarchical report name
  • there's rarely a possibility a user will ever encounter this error condition
saving the changes done to a (sub) document failed committing the changes for document '#name#' failed
  • #name# will be replaced with the title of the affected (sub) document
  • this condition is met when for instance the available disc space at the location of the database document, or the temporary location used by OOo, is insufficient
storing the database document after a successful migration is not successful storing the database document failed
an error (exception) occurs when the migration process tries to gather initial information about the forms/reports contained in the document collecting the forms/reports of the database document failed
  • there's rarely a possibility a user would ever encounter this error
the storage for the JavaScript, Java, BeanShell, or Python scripts of a form/report contains an element which is not a valid script library unexpected #lib# storage element in document '#doc#', named '#element#'
  • #lib# will be replaced with the type of the script library
  • #doc# will be replaced with the document path
  • #element# will be replaced with the actual name of the unexpected element
  • Unless the user manually tampered with the storage of the database document, this error cannot be encountered - the usual OOo user interface does not offer means to create a document which triggers this error
creating the target storage for migrating the JavaScript, Java, BeanShell or Python libraries to the database document failed creating the database document's storage for #scripttype# scripts failed
  • #scripttype# will be replaced at runtime with the concrete script type
  • There's hardly a possibility a user will ever encounter this error
committing the script storage of a sub document failed saving the #scripttype# scripts for document '#doc#' failed
  • #scripttype# and #doc# will be replaced at runtime as usual
  • There's hardly a possibility a user will ever encounter this error
a completely unexpected error (aka exception) occured while migrating the scripts of a form/report general error during migrationg #scripttype# scripts of document '#doc#'
  • #scripttype# and #doc# will be replaced at runtime as usual
a completely unexpected error (aka exception) occured while migrating the macros or dialogs of a form/report general error during macro migration of document '#doc#'
  • #doc# will be replaced at runtime as usual
while trying to adjust a script reference found in the sub document - either in the document events, or in the event bindings of the forms or form controls contained in the document -, an unknown script type was encountered unknown script type: #type#
  • #type# will be replaced at runtime with the actually found script type
  • except the user has a document created in an installation which supported a script type, and script provider, not supported by a default OpenOffice.org installation, it is impossible to encounter this error. Such an unknown script type is currently highly unlikely to exist.
  • This is a recoverable error, in that the respective script reference will simply not be adjusted by the migration process.
while trying to adjust a script reference found in the sub document - either in the document events, or in the event bindings of the forms or form controls contained in the document -, an unknown script language was encountered unknown script language: #lang#
  • #lang# will be replaced at runtime with the actually found script language
  • except the user has a document created in an installation which supported a script type, and script provider, not supported by a default OpenOffice.org installation, it is impossible to encounter this error. Such an unknown script type/language is currently highly unlikely to exist.
  • This is a recoverable error, in that the respective script reference will simply not be adjusted by the migration process.
while trying to adjust a script reference found in the sub document - either in the document events, or in the event bindings of the forms or form controls contained in the document -, the format of the script reference could not be determined unknown script name format: #script#
  • #script# will be replaced at runtime with the actually found script reference
  • This error usually indicates a corrupt document
  • This is a recoverable error, in that the respective script reference will simply not be adjusted by the migration process.
while trying to adjust a script reference found in the sub document, an unexpected error (exception) occurs analyzing/translating the script URL failed; script type: #type#; script: #code#
  • #type# and #code# will be replaced by the script type and script code actually found in the script reference
  • This is a recoverable error, in that the respective script reference will simply not be adjusted by the migration process.
a script descriptor found in the events of a sub document is invalid invalid script descriptor format
  • this error usually indicates a somehow corrupted sub document
  • This is a recoverable error, in that the respective script reference will simply not be adjusted by the migration process.
an unexpected error occurs while adjusting a script reference found in a sub document's script events adjusting events for document '#doc#' failed
  • #doc# will be replaced with the name of the affected sub document, as usual
  • This is a recoverable error, in that the script events in the affected sub document will not be translated
an unexpected error occurs while adjusting the events of the forms / form components in a sub document adjusting form component events for '#doc#' failed
  • #doc# will be replaced with the name of the affected sub document, as usual
  • This is a recoverable error, in that the form/component events in the affected sub document will not be translated
opening the "Scripts" sub storage of a sub document fails with an unexpected error binding to the script storage failed for document '#doc#'
  • #doc# will be replaced with the name of the affected sub document, as usual
after having migrated all script libraries contained in a sub document, removal of the now-useless "Scripts" sub storage of the document fails removing a scripts storage failed for document '#doc#'
  • #doc# will be replaced with the name of the affected sub document, as usual
backing up the document fails backing up the document to #location# failed
within the "Scripts" sub storage of a form or report, a folder is encountered which does not match any of the known script types (Java, JavaScript, Python, BeanShell) unknown script folder '#name#' in document '#doc#'
  • #doc# will be replaced with the name of the affected sub document, as usual
  • #name# will be replaced with the name of the encountered sub storage
an unexpected error (exception) occurs during examining the structure of the "Scripts" sub storage of a form or report examining the 'Scripts' folder failed for document '#doc#'
  • #doc# will be replaced with the name of the affected sub document, as usual
the password verification for a password-protected Basic or Dialog library in a sub document failed password verification failed for document '#doc#', #libtype# library '#name#'
  • #doc# will be replaced with the name of the affected sub document, as usual
  • #libtype# will be replaced with either "%PRODUCTNAME Basic" or "dialog"
  • #name# will be replaced with the name of the library whose password verification actually failed
Summary
Successful Migration
Migration Wizard, Step 4: Summary
  • shows a summary to what changes were made to the document

User Interface Elements

Type Property Value Comment
text particle text The migration was successful. Below is a log of the actions which have been taken to your document.
text particle text Database Document
text particle text saved copy to $location$ $location$ will be replaced at runtime with a file location$
text particle text Form '$name$' $name$ will at runtime be replaced with the actual name of a form document
text particle text Report '$name$' $name$ will at runtime be replaced with the actual name of a report document
text particle text moved $type$ library '$old$' to '$new$' $type will be replaced with either one of "OpenOffice.org Basic", "dialog", "Java", "JavaScript", "Python", "BeanShell". $old$ and $new$ will be replaced with actual names of the library.
text particle text dialog This word will appear as part of the phrase "... moved $type$ library ..." (see above), and will not be translated
text particle text  %PRODUCTNAME% Basic This word will appear as part of the phrase "... moved $type$ library ..." (see above)
text particle text JavaScript This word will appear as part of the phrase "... moved $type$ library ..." (see above)
text particle text BeanShell This word will appear as part of the phrase "... moved $type$ library ..." (see above)
text particle text Python This word will appear as part of the phrase "... moved $type$ library ..." (see above)
text particle text Java This word will appear as part of the phrase "... moved $type$ library ..." (see above)
Unsuccessful Migration
Migration Wizard, Step 4: Summary (for an unsuccessful migration)
  • shows a summary to what errors happened during the migration process

User Interface Elements

Type Property Value Comment
text particle text The migration was not successful. Examine the migration log below for details.

Assigning Macros to Events

  • database documents become eligible to assigning them to document events, such as the event "Open Document"
  • the "Events" page in the Customization Dialog thus will allow event configuration for the current database document, in the very same way it works for all other OOo application's documents
  • the following events are supported, with the very same meaning as in the other applications
    • Create Document
    • Open Document
    • Save Document As
    • Document has been saved as
    • Save Document
    • Document has been saved
    • Close Document
    • Document is closing
    • Activate Document
    • Deactivate Document
    • 'Modified' status was changed
Customizing event assignments for a database document

Miscellaneous

  • The Open Document Format supports specifying scripts directly in the content.xml file in the document package, instead of putting them into separate sub packages of the document file.
    • OOo applications normally support this upon reading the document
    • but upon saving, scripts and macros are always put into separate sub packages
    • OOo Base will not support scripts in the content.xml file for the moment

Implementation Milestones

Timeline

The development of this feature will produce the following milestones:

Milestone Due
M1
  • embedding/organizing/running macros/scripts works
  • the usual suspects (macro selector/organizer, customization dialog) do not display forms/reports anymore, but the database documents instead
  • macros, located in database documents, assigned to form/controls in forms, work as expected
  • you can customize database-document-located macros into toolbars/menus/events of forms/reports, query/table/relation designers, and the table data view
2nd January 2008
M2
  • old documents offer the migration menu entry, but still work as before until migration is done
  • semi-automatic migration works as described in the specification
31st May 2008
M3
  • Assigning macros to database document events (Tools / Customize / Events) works. For instance, it is possible to assign a macro to the OnLoad event of an DB document itself.
31st August 2008
M4
  • loose ends are fixed
  • implement additional database-document-specific events (such as: opening/closing a form/report), which the user can bind macros/scripts to
t.b.d.

Milestone M1 and M2 are considered essential before the feature can be released. Milestone M3 is strongly desired. Milestone M4 is desired to be reached before a release, but not required.

Open Issues

n/a

Future Tasks

  • For the moment, it will not be possible to sign macros embedded in database documents. This is up to a later step.
  • Macro recording will still not be possible in database documents. This is a separate topic, which requires implementations in a completely different area.
  • In the course of the implementation, we fixed the issue which requested to be able to store menu/toolbar/keyboard customizations in form/report documents. That is, you can explicitly tell a certain toolbar/item to appear in one concrete document only. It would be desirable to allow the same for tables and queries, and perhaps even the relation designer: For all of those, you might wish to do a customization for one concrete object (table/query) only, not for all objects of this type.
    Going further, you might even want to have a database-document-wide configuration for all objects of a certain type. That is, you might want to have a certain toolbar appearing in all tables of the database document, but *not* in the tables of other database documents.
  • The migration warning which appears when a document with macros and/or scripts in forms/reports might be annoying to the user - she might actually decide to keep the macros/scripts this way, and never migrate them. To support such a use case, the warning should show a kind of "Don't show this again" check box.
  • It is desirable to have events specific to database documents (for instance: opening forms/reports contained in the database document), which the user can bind document macros to.
  • The migration warning might actually be superfluous - why not start the migration wizard immediately when the document is opened? Of course the "don't show this again" check box would need to be part of the wizard then, and perhaps additional explanations (which at the moment are part of the warning dialog) need to be shown on the first page then.

Appendix

Glossary

Acronym / Abbreviation Definition
Customization dialog is the dialog which allows to customize menus, toolbars, keyboard and event bindings. Reached via Tools / Customize ... in all OpenOffice.org applications. For all aforementioned UI types, it allows to add macros or scripts, for instance, you can customize your toolbar or menu to include a reference certain Basic function. This holds for office-wide macros as well as document-local macros, in which case you usually store the customization in the document only, and not application-wide.

Note that the customization dialog is context-sensitive.

Macro Organizer is the dialog which you open via Tools / Macros / Organize Macros / OpenOffice.org Basic ... in all applications.
Macro Selector is the dialog which allows you to select a single macro. It is invoked whenever the user needs to specify a macro or script function or method, for instance when you choose the "Macro" button on the "Events" tab page of the organizer dialog. Note that there are cases where the macro selector allows to select macros or scripts from all currently-open documents (for instance when invoked via Tools / Macros / Run), and cases where it contains only macros/scripts from the active document (e.g. when invoked from the customization dialog of an active document).

Note that the macro selector is context-sensitive.

context-sensitive In the scope of this document, a UI element (usually a dialog) which displays a hierarchical list of macros and scripts, and allows to select macros and scripts to perform actions on them (editing, executing, and the like), is called context-sensitive when it will display the application-wide and the user-level macros and scripts, plus the macros and scripts located in the document from which this UI element was invoked.

In contrast, UI elements which display all macros and scripts in all documents which are currently opened, are not context-sensitive.

active document is the one document within OpenOffice.org which last got the focus (directly or indirectly, i.e. via one of its child windows).
sub document is a form or report, embedded in a database document

References

Reference Document Check Location (URL)
Specification Process Entry Check [passed/failed] n/a
Product Requirement, RFE, Issue ID available

Possibility to put macros in *.odb files
Impossible to bind a macro to an OpenOffice.org Base document
RFE: add database specific event for macros to the database

Test case specification not available

Contacts

Role Name
Developer Frank Schönheit
Quality Assurance Marc Neumann
Documentation Uwe Fischer
User Experience Bettina Haberer
Personal tools