Milestone 680m233 has been finished recently, containing the child workspace basmgr03. This had three consequences (ordered by increasing significance):

1. The number of my open CWS decreased by 1 to 14. (Hmm. Perhaps next time I feel like doing exorcism I should practice on child workspaces, not on code).

2. Two bugs have been fixed by passing, which will already slightly improve your "scripting experience" in Base:

   • Issue 81217 describes the cryptic "no script" error message when you (first-time) open a database form which contains macros

   • Issue 76129 describes that you could not bind macros to document events (such as OnLoad) using the usual Tools/Customize functionality

3. The final (well, hopefully) foundations in the application framework have been laid, so that we now can embark upon Issue 49133: allow to embed macros in database documents like in the other application's documents.

(
In case you wonder why I talk about "Base" vs. "other applications" here: For historical reasons, Base does not use the non-UNO application framework as Writer/Calc/Draw/Impress/Math do, but started implementation from scratch. This decision, dating some years back, had some good and some bad consequences in the last years – one of them being that often enough, we needed to re-implement the other app's functionality, respectively re-factor it so it can be used everywhere. This is what we did with the Basic-IDE in CWS basmgr03.
)

There's still some open questions around this, though. That is, implementing the functionality to embed Basic macros in an ODB file is the first step. Of course you will be able then to execute those macros, to edit them in the IDE, and the like – as you know it from the other applications.

But surely you also want to bind those macros to elements in your forms and macros. Say you want to have a button in a form, which, when pressed, executes a macro located in the embodying database document. Looking at how such binding is done technically, the script is represented as URI, which later is fed into the scripting framework. The URI might be something like vnd.sun.star.script:Standard.Module1.Main?language=Basic&location=document. Note there's the "location=document" parameter: It specifies the function "Main" should be looked up in the module "Module1" in the Library "Standard" in the document's Basic. In contrast, if it should be looked up in the application-wide Basic, the parameter would be "location=application". (Just noticed that chapter 19.6.1 of the Developer's Guide talks about allowed locations being "document", "user", and "share". Seems this is somewhat outdated.)

So, we need to think about how to design a hierarchy of document-local Basic scripts. Should they all be subsumed in the "document" location? That is, if location=document is specified, the macro could be in the form (if there is such a macro), or in the database document which this form belongs to. Or, should a new location type be introduced? location=parentdocument? Doesn't really sounds convincing to me.

Well, for the moment I'm looking forward to start the core implementation. It may be that in a first step, we won't solve the above problem. Even if so, it would still mean you already can embed Basic in .odb files, and you can use it to implement logic in your database application (e.g. by configuring it into the document's toolbar or menu). That alone would be a major step forward, don't you think?

If you ever used Base with forms and reports, you most probably already noticed the following: Say you open a form, which comes up with a certain size, work with it, then close it. Afterwards, you open an existing, or create a new text document. Guess what? This text document comes up with the same size as previously your database form. Also, if you previously switched on, say, the Drawing Object Properties toolbar in Writer, it will also be switched on in all your database forms. If you switch it off there, it will also be switched off in your Writer documents. Same for all other toolbars, and for all your menu/toolbar/keyboard customizations – they're all shared between Writer and database forms.

This usually is quite annoying, since the tasks you do in both modules are different, so your working habits probably are different, too. Also – but maybe that's only me – it looks rather unprofessional, doesn't it?

Conceptually, the reason is OpenOffice.org's understanding of modules: Toolbars, menus, keyboard accelerators, as well as window position and size, are attributes of a module (you might look into your installation's share/config/soffice.cfg/modules directory to get an impression). While different applications in OpenOffice.org define different modules – e.g., Calc defines an own module, Writer does, Impress does, plus some more –, database forms are implemented using a somewhat customized Writer, thus they're identified as being the Writer module. Until now.

The child workspace fwkdbdesign01 introduces a concept where modules are separated from applications (thanks to Andreas Schlüns from the framework team for answering our long-year begging!). That is, using the new UNO interface XModule, we can now programmatically change the identifier of a module. Doing so, we can define database forms to be a module different from Writer. As an immediate consequence, all symptoms mentioned above (plus some more, for instance flickering in the Form Design toolbar when initially opening a Writer document or database form) are gone. On a medium term, we are able to better customize form UI to the tasks of database form creation, without affecting Writer. For instance, we could remove (or at least hide from the top-level) all the functionality which is relevant to Writer only, but not to form design.

So, I'm looking forward to this CWS being integrated (it's in QA currently), and I hope I'm not the only one who thinks that this is a change for the better in Base's usability.