Creating reports in VB code

  • Thread starter Thread starter Max Moor
  • Start date Start date
M

Max Moor

Hi All,
I'm trying to learn how to make reports in code, and have a couple
questions. If I'm catching on, it appears I need at least a simple report
to exist, saved. If I open it in acViewDesign mode, hidden, I can call
CreateGroupLevel and CreateReportControl a few times to place the controls
I want.
Once I've done with this part, how do I put it in preview mode and
unhde it? I've been perusing the methods, but can't find it.
Any help on this, or other thoughts on methodology, would be
appreciated.

Max
 
Max,

If you close it and save changes, you can now reopen it in
preview mode and it should display fine. If you need to
redraw everything again, you could easily build a routine to
delete all existing controls the next time you open it for
modifications.

Gary Miller
 
Max said:
Hi All,
I'm trying to learn how to make reports in code, and have a couple
questions. If I'm catching on, it appears I need at least a simple report
to exist, saved. If I open it in acViewDesign mode, hidden, I can call
CreateGroupLevel and CreateReportControl a few times to place the controls
I want.
Once I've done with this part, how do I put it in preview mode and
unhde it? I've been perusing the methods, but can't find it.
Any help on this, or other thoughts on methodology, would be
appreciated.
Click to expand...


Soap Box time. Doing this kind of thing at run time is a
Bad Idea! The Create methods are for design time wizard
type procedures, not in response to user activities. This
kind of manipulation is a heavy duty operation that greatly
increases the chances of your database being corrupted and
will certainly cause massive bloat.

The standard technique to adapt a report to specific
conditions is to precreate all of the controls and group
levels that might be needed and then modify their properties
at run time. The controls can be made visible or not as
needed and the group levels can be manipulated in the
report's Open event procedure.

If you need help doing these things, post back with more
details of the options you need in the report and we'll see
if there's a way to do it without messing around with the
Create methods.
 
Soap Box time. Doing this kind of thing at run time is a
Bad Idea! The Create methods are for design time wizard
type procedures, not in response to user activities. This
kind of manipulation is a heavy duty operation that greatly
increases the chances of your database being corrupted and
will certainly cause massive bloat.

The standard technique to adapt a report to specific
conditions is to precreate all of the controls and group
levels that might be needed and then modify their properties
at run time. The controls can be made visible or not as
needed and the group levels can be manipulated in the
report's Open event procedure.

If you need help doing these things, post back with more
details of the options you need in the report and we'll see
if there's a way to do it without messing around with the
Create methods.
Click to expand...


Hi Marshall,
Soap box away. What you say makes sense. The fact is that I'd
rather do what you suggest than write what seems like it could be some
relatively hairy code. I suppose I can see how to do this, except for a
couple of things.

Say I have a table with 10 fields, 6 of which could be chosen as a
grouping level (a max of three at any one time). If I understand you, I
would create a form with all six groupings defined, and a detail section
containing all 10 fields.

When I open the report, I would pass in some OpenArgs that would
have the form specify itself (like moving the detail stuff around). The
part I don't see how to do is changing the groupings around.

For example, say I design a generic report with fields 1, 2, 3, 4,
5, and 6 as groupings 1, 2, 3, 4, 5, and 6, respectively. Now the user
wants a report with groupings 1, 2, and 3 as fields 5, 3, and 1. How do
I blow away the groupings of fields 2, 4, and 6, and change the order of
the other three?

- Max
 
Marshall Barton wrote
Max said:
Soap box away. What you say makes sense. The fact is that I'd
rather do what you suggest than write what seems like it could be some
relatively hairy code. I suppose I can see how to do this, except for a
couple of things.

Say I have a table with 10 fields, 6 of which could be chosen as a
grouping level (a max of three at any one time). If I understand you, I
would create a form with all six groupings defined, and a detail section
containing all 10 fields.

When I open the report, I would pass in some OpenArgs that would
have the form specify itself (like moving the detail stuff around). The
part I don't see how to do is changing the groupings around.

For example, say I design a generic report with fields 1, 2, 3, 4,
5, and 6 as groupings 1, 2, 3, 4, 5, and 6, respectively. Now the user
wants a report with groupings 1, 2, and 3 as fields 5, 3, and 1. How do
I blow away the groupings of fields 2, 4, and 6, and change the order of
the other three?
Click to expand...

If you'll never need more that three group levels, then
create just the three. Then use code like the following in
the report's Open event.

You will have to decide how you want to pass the report
options info to the report (i.e. which fields are grouped at
which level). You mentioned using the report's OpenArgs,
but I don't know how you want to utilize it to contain so
much information. Possibly, something along the lines of a
semicolon delimited list of keyword=value. Part of the
OpenArgs would look something like
"GL0=field5;GL1=field3;GL2=field1" The report can then use
the InStr function to parse out each value:

Args = Me.OpenArgs
Pos = Instr(Args, "GL1=") + 4
Me.GroupLevel(0).ControlSource = _
Mid(Args, Pos, InStr(Pos, Args, ";") - Pos)
Pos = Instr(Args, "GL2=") + 4
Me.GroupLevel(1).ControlSource = _
Mid(Args, Pos, InStr(Pos, Args, ";") - Pos)
Pos = Instr(Args, "GL3=") + 4
Me.GroupLevel(2).ControlSource = _
Mid(Args, Pos, InStr(Pos, Args, ";") - Pos)

Since that might be a little messy, you might be willing to
directly reference the form where the user can specify the
report options. This is not quite as clean a design since
the report would have to be aware of the form, but if you
want to do it this way, the code in the report could be like
this:

With Forms!theform
Me.GroupLevel(0).ControlSource = .txtGl1
Me.GroupLevel(1).ControlSource = .txtGl1
Me.GroupLevel(2).ControlSource = .txtGl1
End With

Another way to pass a lot of info from a form to a report is
to have a Public Collection declared in a standard module
and have the form set its members to the options and values.
This would look like:

Set colReportArgs = Nothing ' Clean out any old stuff
Set colReportArgs = New Collection
With colReportArgs
.Add "field5", "GL1"
.Add "field3", "GL2"
.Add "field1", "GL3"
End With
Do Cmd.OpenReport . . .

Then the code in the report could be:

Me.GroupLevel(0).ControlSource = colReportArgs("GL1")
Me.GroupLevel(1).ControlSource = colReportArgs("GL2")
Me.GroupLevel(2).ControlSource = colReportArgs("GL2")
 
If you'll never need more that three group levels, then
create just the three. Then use code like the following in
the report's Open event.
Click to expand...

....


Thanks, Marshall. You've given me a lot of good info. I'm not sure yet if
I want to tie the report to the one form, but maybe. At least I know what
to do now, in either case. Thanks again!
 
Back
Top