Hallo Frank,
Thanks again for your extendet explenation, as a says before there is
to match knowledge who's only in your brain and not somewhere else to
find :-)
My goal is indeed to run (open) forms and reports with additional change
in the source and the filters and have no toolbars etc... I must also
keep my users away from the DB doc. On compagny level i make the DB doc
available for registration in OO, all users can open the DB doc but as
soon they tiy to acces a table, query form or report there is a user and
passwordt asked. This password is only stored in the scrambled macro.
I think thats a healty start to use OO as backend for all Database
related applications in our compagny
still 2 questions:
- 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)
But i will do some reshearch and come back when i do not find the
answers elsewhere
Greetz
Fernand
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
