Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.