Referencing CurrentSection at runtime.

[Marat]

I need to call the same function from every section of the report. In the
function I am traversing the fields that are about to print. I coded it like
this:



Private Sub PageHeaderSection_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call
DumpPrintingData(Me.Section("PageHeaderSection"))

End Sub


Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call DumpPrintingData(Me.Section("Detail"))

End Sub




All works fine when the argument explicitly sends the section that is about
to print: Me.Section("Detail") or Me.Section("PageHeaderSection")

I want to reference the section so that I could make the call from all
section with the same code like this:

Private Sub PageHeaderSection_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call CountSectionControls(CurrentSection)

End Sub


Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call CountSectionControls(CurrentSection)

End Sub


Of course there is no such thing as "CurrentSection".

What is the the appropriate argument I could send to the function so I could
determine which particular section is printing?


TIA!
Marat.

 

[Marshall Barton]

I need to call the same function from every section of the report. In the
function I am traversing the fields that are about to print. I coded it like
this:

Private Sub PageHeaderSection_Print(Cancel As Integer, PrintCount As Integer)
If PrintCount = 1 Then Call
DumpPrintingData(Me.Section("PageHeaderSection"))

End Sub


Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call DumpPrintingData(Me.Section("Detail"))

End Sub


All works fine when the argument explicitly sends the section that is about
to print: Me.Section("Detail") or Me.Section("PageHeaderSection")

I want to reference the section so that I could make the call from all
section with the same code like this:

Private Sub PageHeaderSection_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call CountSectionControls(CurrentSection)

End Sub


Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

If PrintCount = 1 Then Call CountSectionControls(CurrentSection)

End Sub


Of course there is no such thing as "CurrentSection".

What is the the appropriate argument I could send to the function so I could
determine which particular section is printing?

I believe there is no way to do that.

However, if you can do away with the If PrintCount part of
that and if you make CountSectionControls a function, then
you can call the function directly from the OnPrint property
setting and avoid having a separate event procedure for each
section. You still need to specify the section so the
property setting would look like:
=CountSectionControls(0)
for the detail section.

The function would then look something like:
Public Function CountSectionControls(SecID As Integer)
. . .
For Each ctl In Me.Section(SecID).Controls
. . .

 

[Marat]

Marsh,

Thank you very much for your response.

So, you are saying there is no way to do this.

That is a hard fall to my strategy! I also couldn't find it, although I
somehow feel there must be a way.

More generaly, I need to determine the name of the function from which the
current function was called.

Perhaps you can tell me whether it possible to determine at run time the
name of the function where the code is presently executing?

Something like this:

Function MyFunction() as String
' would always returns "MyFunction"
MyFunction= ThisFunction.Name
End Function


Thank you,
Marat.

 

[Marshall Barton]

You can not do that either. But, on the other hand, you
always know the name of the function you are in because you
declared the function with its name. The typical approach
to this kind of thing is to use a local variable with the
function's name:

Function MyFunction() as String
Const cstrMyName As String = "MyFunction"

' would always returns "MyFunction"
MyFunction= cstrMyName
End Function

This simple work around only has the minor inconvenience of
one additional line of code, so it's not all that onerous.

 

[Marat]

Marsh,

The idea was to insert a line of code in all reports with VBA code. Other
method could be to sink the "print" events of running report and use the same
function call to do something with the section’s data right before it prints.

At run-time, while in break mode, one can see the name of proc where the
code is executing. Therefore, I automatically assumed it is available.
Obviously, the proc name is recorded in a memory location someplace. I don't
understand why this is not possible to obtain.

This also applies to a calling sub's name - I understand that there is no
way to determine the calling sub's name either. Why not? All this info is
available in the Call Stack (ctrl-L) in break mode. May be an API?



I am really surprised by this. Do you happen to know why it is so and
whether this will ever change? Perhaps a security issue is the reason? Must
be something worthwhile to sacrifice access to obviously existing information
- wouldn't you agree?.

Thank you, Marshall, for your time and trying to help. At least I can stop
searching now with the clear conscience. I just hate to admit a defeat of a
perfectly sound strategy.

Marat.

You can not do that either. But, on the other hand, you
always know the name of the function you are in because you
declared the function with its name. The typical approach
to this kind of thing is to use a local variable with the
function's name:

Function MyFunction() as String
Const cstrMyName As String = "MyFunction"

' would always returns "MyFunction"
MyFunction= cstrMyName
End Function

This simple work around only has the minor inconvenience of
one additional line of code, so it's not all that onerous.
--
Marsh
MVP [MS Access]

So, you are saying there is no way to do this.

That is a hard fall to my strategy! I also couldn't find it, although I
somehow feel there must be a way.

More generaly, I need to determine the name of the function from which the
current function was called.

Perhaps you can tell me whether it possible to determine at run time the
name of the function where the code is presently executing?

Something like this:

Function MyFunction() as String
' would always returns "MyFunction"
MyFunction= ThisFunction.Name
End Function

 

[Marshall Barton]

You can insert the Const statement in every VBA procedure
using a design time VBA procedure that makes use of the
Module onject's properties and methods. There are even
utilities kicking around to do that. One of the packages
available from FMS Inc. includes this as part of their
generalized auto error handler generator.

The place where this has been a sore point for VBA
programmers since Access 2 is in the area of a trying to use
a single error handler procedure throughout an application.
Unfortunately, the error handling features in VBA are so
powerful that determining what is an error and where an
error was triggered is an ambiguous operation that can only
be determined by the application programmer, not by looking
at the call stack (even if we could get to it).

My bottom line on this issue is that I'm pretty sure you can
do what you want, but you will have to use code in your
procedures instead of a built-in VBA feature. Since the
needed code is almost certainly something that can be
parametized, you can create a moderately simple utility
routine to insert it into your all of your procedures in one
shot.

 

[Marat]

What you recommend, Marsh, can be coded, indeed - one report at a time. But I
still do not see a way to accomplish my goal - to get a good grip on the
runtime instance of the report without having to change code of the report
itself in design time.

Perhaps I need to move to .NET C# - not such problems there, I heard.


Thanks for shedding some light on this for me.
Marat.

You can insert the Const statement in every VBA procedure
using a design time VBA procedure that makes use of the
Module onject's properties and methods. There are even
utilities kicking around to do that. One of the packages
available from FMS Inc. includes this as part of their
generalized auto error handler generator.

The place where this has been a sore point for VBA
programmers since Access 2 is in the area of a trying to use
a single error handler procedure throughout an application.
Unfortunately, the error handling features in VBA are so
powerful that determining what is an error and where an
error was triggered is an ambiguous operation that can only
be determined by the application programmer, not by looking
at the call stack (even if we could get to it).

My bottom line on this issue is that I'm pretty sure you can
do what you want, but you will have to use code in your
procedures instead of a built-in VBA feature. Since the
needed code is almost certainly something that can be
parametized, you can create a moderately simple utility
routine to insert it into your all of your procedures in one
shot.
--
Marsh
MVP [MS Access]

The idea was to insert a line of code in all reports with VBA code. Other
method could be to sink the "print" events of running report and use the same
function call to do something with the section’s data right before it prints.

At run-time, while in break mode, one can see the name of proc where the
code is executing. Therefore, I automatically assumed it is available.
Obviously, the proc name is recorded in a memory location someplace. I don't
understand why this is not possible to obtain.

This also applies to a calling sub's name - I understand that there is no
way to determine the calling sub's name either. Why not? All this info is
available in the Call Stack (ctrl-L) in break mode. May be an API?

I am really surprised by this. Do you happen to know why it is so and
whether this will ever change? Perhaps a security issue is the reason? Must
be something worthwhile to sacrifice access to obviously existing information
- wouldn't you agree?.

Thank you, Marshall, for your time and trying to help. At least I can stop
searching now with the clear conscience. I just hate to admit a defeat of a
perfectly sound strategy.

 

[Marshall Barton]

I don't know what goodies are available in .Net, but for
sure it doesn't have the Access report features, so you will
run into a ton of other issues.

Yes, of course the report's design must be changed, and you
will probably want to at least look at each of them to make
sure everything is the way you want it to be. But, you do
not have to modify them one at a time. You can create the
design aid utility to change every module in your
application in one fell swoop just by looping through the
Document collections in the Modules, Forms and Reports
Containers.