Bug 42796 - Macro assigned to dataform Before Unload or While Unloading events are not called when form container is closed

[Lionel Elie Mamane]

On Thu, Apr 04, 2013 at 12:27:56PM +0100, Noel Power wrote:
> On 04/04/13 11:03, Lionel Elie Mamane wrote:
>> On Thu, Apr 04, 2013 at 11:08:54AM +0200, Jan Holesovsky wrote:
>>> mcmurchy1917-libreoffice at yahoo.co.uk píše v St 27. 03. 2013 v 09:46+0000:

>>>> I've fallen foul of this bug in recent days so have decided to have a
>>>> look at it to see if I can provide a patch.
>>> Thank you for the offer of help! :-) (...) I'm CCing Noel and Lionel
>>>- macros are Noel's area, and databases Lionel's; (...)

>>>> In the bug report it was confirmed that a macro assigned to either the
>>>> Before Unloading or When Unloading events of a dataform are not called
>>>> when the form document is closed.
>>>> However, when editing a form and the "Design Mode" option is
>>>> toggled the events are called. Also the events when the form is
>>>> loaded are called under all circumstances.

> First the triggering when in designmode isn't unfortunately that
> helpful ( although it does identify relevant code ) because there
> appears to be specific handling for the designmode e.g. see

> FmFormView::ChangeDesignMode

>  258     // --- 4. load resp. unload the forms
>  259     FmFormPage*  pCurPage = GetCurPage();
>  260     if ( pCurPage )
>  261     {
>  262         if ( pFormShell && pFormShell->GetImpl() )
>  263             pFormShell->GetImpl()->loadForms( pCurPage, (
> bDesign ? FORMS_UNLOAD : FORMS_LOAD ) );
>  264     }

> In the normal case of editing the forms ( which presumably that is
> the workflow to normally trigger the event ? )

Not sure what you meant exactly here, since the terminology is quite
confused in the Base UI; let's clarify it first.

In a Base window, in the left pane, item "Forms". The items in the
lower right pane are implicitly called by the UI "Form", but we'll
here call them "Form Document" to disambiguate.

A Form Document is an OpenDocument Text document which *contains*
things that the UI *also* calls "Form", but we'll here call them
"DataForm". These can be seen by opening the "Form Navigator" by
clicking on the button of that name in the "Form Design" toolbar
(there is often only one DataForm, but not always; when there are
several, they are usually organised in a hierarchy such as one
DataForm is the (grand-grand-...)parent of all others).

The DataForm in turn contains Form controls, such as e.g. Text Box,
List Box, Check  Box, ... but also (sub)DataForms.


The terminology being fixed, we can speak:

A Form Document can be opened in "normal" mode (with the "Open"
command) or in "Design" mode (with the "Edit" command).

Each of the Form Document, DataForm and form controls can have events
associated.

IMO, it is *not* desirable for *any* event to fire when a form
document is opened in design mode. Design mode is about creating /
changing (designing) the form document (~job of programmer), while
reaction to events is about stuff happening automatically when *using*
the form (~job of user).

Form Design: add/remove/resize a form control, change the macros
             attached to its events, ...

Form Use: change data stored in a database using the form

So if by "editing the form" you meant "open the form document in
normal (NON-Design) mode and change the values in controls", then
yeah; that's the workflow to normally trigger the various events.

If by "editing the form" you meant "open the form document in design
mode and do anything there", then no, that's not the typical workflow
to trigger the events.


-- 
Lionel