« Return to Thread: Macro & ODB documents
Re: Macro & ODB documents
by frank.schoenheit
::
Rate this Message:
Hi Paolo,
> Good to hear. This finally corrects a severe inconsistency affecting
> former versions.
> However, if you launch a macro from the IDE, ThisComponent points
> correctly to the ODB document, but if you launch the same macro from a
> button placed into a form-document, ThisComponent points to the
> form-document itself.
>
> This is not a small problem: users will soon start looking for a
> solution. Most probably many of them will not recognize the exact terms
> of the problem, they will just learn that using ThisComponent.Parent
> sometimes does the job.
> And when this bug will be corrected, all their code will simply stop
> working.
This is not a bug, this behaves as designed:
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Global_Variables_in_Basic_Macros.
See the discussion page of the spec for a reasoning. One major problem
which would immediately occur if ThisComponent were the DB doc is the
following: Scripts bound to menu or toolbar items, working on the
document from which they're invoked, would need to behave differently
depending on whether they're invoked for a form/report or any other
document type.
If you need access to the database document regardless of the place of
invocation, use ThisDatabaseDocument. If you need access to the
sub/document from which the macro was invoked, use ThisComponent.
> But IMHO the real problem is elsewhere:
> Normal users (not developers) are struggling with macro in ODB documents
> from the beginning.
> They fill their OOoBase documents with tons of complicated source code,
> that mostly they not even understand, and all this pain just because
> they would like to launch a form from another.
>
> Put a simple way to do this job (for example a dedicated property in
> form buttons) and 99.99% of OOoBase users will no more need of any macros
I definitely wouldn't agree to the "99.99%", but for sure that would be
a reasonable extension of the existing functionality. Did you by chance
vote for it when we asked for user input? :)
(http://blogs.sun.com/GullFOSS/entry/if_you_had_3_wishes)
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
> Good to hear. This finally corrects a severe inconsistency affecting
> former versions.
> However, if you launch a macro from the IDE, ThisComponent points
> correctly to the ODB document, but if you launch the same macro from a
> button placed into a form-document, ThisComponent points to the
> form-document itself.
>
> This is not a small problem: users will soon start looking for a
> solution. Most probably many of them will not recognize the exact terms
> of the problem, they will just learn that using ThisComponent.Parent
> sometimes does the job.
> And when this bug will be corrected, all their code will simply stop
> working.
This is not a bug, this behaves as designed:
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Global_Variables_in_Basic_Macros.
See the discussion page of the spec for a reasoning. One major problem
which would immediately occur if ThisComponent were the DB doc is the
following: Scripts bound to menu or toolbar items, working on the
document from which they're invoked, would need to behave differently
depending on whether they're invoked for a form/report or any other
document type.
If you need access to the database document regardless of the place of
invocation, use ThisDatabaseDocument. If you need access to the
sub/document from which the macro was invoked, use ThisComponent.
> But IMHO the real problem is elsewhere:
> Normal users (not developers) are struggling with macro in ODB documents
> from the beginning.
> They fill their OOoBase documents with tons of complicated source code,
> that mostly they not even understand, and all this pain just because
> they would like to launch a form from another.
>
> Put a simple way to do this job (for example a dedicated property in
> form buttons) and 99.99% of OOoBase users will no more need of any macros
I definitely wouldn't agree to the "99.99%", but for sure that would be
a reasonable extension of the existing functionality. Did you by chance
vote for it when we asked for user input? :)
(http://blogs.sun.com/GullFOSS/entry/if_you_had_3_wishes)
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: Macro & ODB documents
| Free embeddable forum powered by Nabble | Forum Help |
