Hi Fernand,
> I was a bit to hasty yesterday, there is still a problem: oreport =
> oreports.getbyname("Jobbons1")
> oReport has no component !
The "component" of a document definition is the "document" represented
by it. For a form, or a text-based (old style) report, this is merely
the Writer document.
For a new-style report, it is the report designer component (being a
css.report.ReportDefinition instance. Yes, the namings might be somewhat
confusing :) ).
The component only exists when the respective sub document was really
loaded - in case of new-style reports, this means that the *report
designer* must have been opened. Note that "open" at a document
definition object does not open it for design - that's what "openDesign"
is intended for.
So, since your code actually never loaded the report designer, you never
*should* have a component. The fact that you have one seems more like a
bug to me - I suppose that from the first run of the macro, some
internal objects have not been cleared completely, in particular, the
report designer, which was implicitly opened for executing the report,
still lingers around.
Interestingly, you *always* (no matter how often you run the macro) get
a NULL component when the database document does not contain macros.
This, together with the fact that you're asked for macro handling in the
document at the time you open the *report*, indicates there's something
strange going on.
Seeing what you want to reach with your macro - executing a report with
a certain additional -, I think how the API *should* look like is as
follows:
aArguments(0).Name = "Filter"
aArguments(0).Value = <desired_filter>
oReports.loadComponentFromURL( <report_name>, "_blank", 0, _
aArguments() )
That is: loadComponentFromURL should be the preferred way, since it
allows you to pass other parameters. Also, ActiveConnection should not
be necessary, as it can be obtained internally, from the database
document's current (and only) controller (Well, I am not completely sure
this is a good idea, since this means document-level objects reaching
through to the UI objects, which might be bad.). OpenMode, too, should
not be necessary - it can be defaulted internally.
Well, this doesn't work, currently, as (I suppose, didn't check) the
Filter is not routed to the to-be-executed report.
So, with the current API, I suppose the solution would be along those
lines (didn't try):
- obtain the data source, and the database document
- retrieve the Args of the document, replace the existing
MacroExecutionMode argument with MacroExecMode.ALWAYS (so you're
not asked later on)
- do an attachResource on the document, with the modified args
- open the report designer hidden
since this crashs until CWS dba33e is integrated, open it
visibly, and immediately do a
component.CurrentController.Frame.ContainerWindow.setVisible(FALSE)
- set the report designers filter
- open/run the report
(- file an issue requesting that it should be possible to override the
Filter/Order/GroupBy/Having clauses, i.e. one should be able to
programmatically execute a report, and just pass those parameters,
instead of manually tampering with the report designer)
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
