Use a Variable to set a Variable

D

dch3

I asked this question differently in another post and got an answer that
didn't answer the question...

So is it possible to create a function that takes a parameter which
represents a global variable and in the function set the variable? Basically
I want a function whereby I can pass in a variable NAME and have the function
set the variable.

NOTE: YES, YES, YES! I am fully aware that I could explicitly set the
variable (mySystemName = "Hello World"), *BUT* I want a function that is
generic and can be used regardless of the variable name that needs to be set.
The function will be used in conjunction with the .OpenArgs statement of the
..OpenForm and .OpenReport methods of DoCmd.

As in...

call setGlobalVariable("mySystemName", "Hello World") will set the global
variable mySystemName to "Hello World"

Global mySystemName as Variant
Global myNetworkName as Variant

sub setGlobalVariable (strVariableName as String, varValue as Variant)

[statement which recognizes strVariableName as a DIM'd variable] = varValue

end sub
 
D

dch3

Darn. I'll just have to come with a spiffy, generic way to deal with
situations where I need to pass multiple values to a Form/Report via .OpenArgs

Douglas J. Steele said:
I don't believe it's possible.

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


dch3 said:
I asked this question differently in another post and got an answer that
didn't answer the question...

So is it possible to create a function that takes a parameter which
represents a global variable and in the function set the variable?
Basically
I want a function whereby I can pass in a variable NAME and have the
function
set the variable.

NOTE: YES, YES, YES! I am fully aware that I could explicitly set the
variable (mySystemName = "Hello World"), *BUT* I want a function that is
generic and can be used regardless of the variable name that needs to be
set.
The function will be used in conjunction with the .OpenArgs statement of
the
.OpenForm and .OpenReport methods of DoCmd.

As in...

call setGlobalVariable("mySystemName", "Hello World") will set the global
variable mySystemName to "Hello World"

Global mySystemName as Variant
Global myNetworkName as Variant

sub setGlobalVariable (strVariableName as String, varValue as Variant)

[statement which recognizes strVariableName as a DIM'd variable] =
varValue

end sub
 
D

dch3

The point of the exercise is finese and technique.

The underlying issue deals with the desire to pass multiple values into a
Form or Report via the .OpenArgs property - which is a string as opposed to
an array or collection. Given that I want something that can extract the
parameters for any form or any report, I decided that I wanted to implement a
URL Query String-esque approach (http://en.wikipedia.org/wiki/Query_string).
This would allow for any number of parameters to be passed to a Form/Report
and then extracted as needed. I might go so far as writing shells for each
Form/Report that takes .OpenArgs so that the assorted parameters show up via
Intelisense along the lines of ...

Sub openFormfrmManifest(Optional strShowDetail as String, Optional
strWindowMode as String, Optional blnSelectRecordOnOpen as Boolean, Optional
intStartupRecordId as Integer)

[Appropriate Code]
DoCmd.OpenForm [parameters],,"paramShowDetail=" & strShowDetail &
"&blnSelectRecordOnOpen=" & blnSelectRecordOnOpen
[Addl Code]

end sub

The idea is to centralize the code that opens the form/report so that you
don't have to remember any additional statements that have to be executed -
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.

Hunter57 via AccessMonster.com said:
Hi,

I use a hidden form that is unbound. I store whatever I need there and can
get the data anytime and anyplace I want in Access: myVariable = Forms!
frmHidden!MyTextBox or myVariable = Form_frmHidden.MyTextBox. Unlike a global
variable, you will not loose your data if you have an unhandled error. You
can store any type of data and any amount of data.

Patrick Wood
http://gainingaccess.net

Darn. I'll just have to come with a spiffy, generic way to deal with
situations where I need to pass multiple values to a Form/Report via .OpenArgs
I don't believe it's possible.
[quoted text clipped - 30 lines]

--
Hunter 57
http://churchmanagementsoftware.googlepages.com/home

Message posted via AccessMonster.com
 
D

dch3

..OpenArgs only takes a string. If you're only going to be passing in a single
value, its not a problem. If you want to be able to pass in multiple values,
you have to come up with some way of extracting the values from the string.
Also, if there are situations where you're only passing in just a couple of
the possible parameters - the form/report code supports 10 and you're only
passing in 3 - the code has to be able to identify which of 3 of the 10 were
passed in. For Forms this probably wouldn't be used - or seldomly at best.
For Reports, it could be used multiple times. For example, its entirely
probable that you'd have a report that provides detail as well as multiple
levels of subtotals. In some situations, you might want to run the report
just showing subtotals or totals. The .OpenArgs would be used to control
wether or not the detail is displayed as well as changing the title of the
report appropriately. Another example might be a situation where you have a
nation-wide report that groups everything by region. Its feasible that the
report could be run for a specific region by simply setting the WHERE
parameter and then passing in a new title for the report "SUMMARY - REGION
1", but still display the detail.

The reason for spinning out the DoCmd to its own sub for each form / report
is to provide the developer (me actually) with the ability to see what
parameters the form / report takes in the .OpenArgs as well as centralizing
any code that needs to run before or after the DoCmd. Basically applying a
form of encapsulation (google it).

The parsing of the string WILL happen in the Open event, but will be spun
out to a generic SUB which will handle any and all situations. (Its actually
already written and working like a charm.) It actually takes the .OpenArgs
string, breaks it apart and loads up a global array which a sister SUB then
uses to retrieve the specific values.

The general idea is to introduce a consistent method of passing values into
a Form/Report and then retrieving them. (Not to mention that the particular
approach is consistent with using a QueryString in web development.

Hunter57 via AccessMonster.com said:
Hi dch3,

I am afraid I do not understand what advantage you are trying to gain. What
you are trying to do appears to me to be merely duplicating the functionality
we already have with the OpenForm and OpenReport Method of the DoCmd Object.

As to using OpenArgs, we already have the ability to pass whatever strings we
want. which we can parse when the Form or Report has the On Open Event. Also,
since the Form or Report cannot do anything with OpenArgs until the On Open
Event occurs it seems to me that OpenArgs alone cannot be used to accomplish
all that you want to do.

Best Regards,
Pat
The point of the exercise is finese and technique.

The underlying issue deals with the desire to pass multiple values into a
Form or Report via the .OpenArgs property - which is a string as opposed to
an array or collection. Given that I want something that can extract the
parameters for any form or any report, I decided that I wanted to implement a
URL Query String-esque approach (http://en.wikipedia.org/wiki/Query_string).
This would allow for any number of parameters to be passed to a Form/Report
and then extracted as needed. I might go so far as writing shells for each
Form/Report that takes .OpenArgs so that the assorted parameters show up via
Intelisense along the lines of ...

Sub openFormfrmManifest(Optional strShowDetail as String, Optional
strWindowMode as String, Optional blnSelectRecordOnOpen as Boolean, Optional
intStartupRecordId as Integer)

[Appropriate Code]
DoCmd.OpenForm [parameters],,"paramShowDetail=" & strShowDetail &
"&blnSelectRecordOnOpen=" & blnSelectRecordOnOpen
[Addl Code]

end sub

The idea is to centralize the code that opens the form/report so that you
don't have to remember any additional statements that have to be executed -
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.
[quoted text clipped - 15 lines]
 
D

dch3

Each form/report using OpenArgs will have their own sub which will contain
any additional code needed to manipulate the form/report on the calling side
as in the example below. It might very well be that the sub contains a single
statement, but it will streamline things in the event that the same basic
code needs to be executed before and/or after the DoCmd statement.

Sub openfrmOrders(Optional strWHEREStatement as String, Optional
[parameter1] as string, Optional [parameter2] as String...)

[Any relevant code...]

DoCmd.OpenReport ..., strWHEREStatement, ... , "open args string"

[Any relevant code...]

end sub

AccessVandal via AccessMonster.com said:
Form/Report that takes .OpenArgs so that the assorted parameters show up via
Intelisense along the lines of ...

Seems to me that you're refering to class objects? You might want to create a
class module for this.

Do a google search on access class module. Or someone might be good at it
might give you some advice.
The point of the exercise is finese and technique.

The underlying issue deals with the desire to pass multiple values into a
Form or Report via the .OpenArgs property - which is a string as opposed to
an array or collection. Given that I want something that can extract the
parameters for any form or any report, I decided that I wanted to implement a
URL Query String-esque approach (http://en.wikipedia.org/wiki/Query_string).
This would allow for any number of parameters to be passed to a Form/Report
and then extracted as needed. I might go so far as writing shells for each
Form/Report that takes .OpenArgs so that the assorted parameters show up via
Intelisense along the lines of ...

Sub openFormfrmManifest(Optional strShowDetail as String, Optional
strWindowMode as String, Optional blnSelectRecordOnOpen as Boolean, Optional
intStartupRecordId as Integer)

[Appropriate Code]
DoCmd.OpenForm [parameters],,"paramShowDetail=" & strShowDetail &
"&blnSelectRecordOnOpen=" & blnSelectRecordOnOpen
[Addl Code]

end sub

The idea is to centralize the code that opens the form/report so that you
don't have to remember any additional statements that have to be executed -
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.
 
M

Michel Walsh

Using Split could be fine, but that assumes you may have to encode your data
to strings.

Another solution is to use a collection of collections. Have a first
collection, global to the whole application, let us call it oCol.

Next, define all the arguments you want to pass inside a collection:

Dim mCol As New Collection
mCol.Add 33, "zozo"
mCol.Add Now(), "when"
mCol.Add 1 / 3, "oneThird"

here, 3 arguments, zozo, when, and oneThird are added to mCol.


Add the collection to oCol:


If oCol Is Nothing Then Set oCol = New Collection

oCol.Add mCol, "Report1"



And use the name you supplied, in oCol, for your collection as OpenArgs:


DoCmd.OpenReport "Report1", OpenArgs:="Report1"


You can then, inside the report, use:


Dim xCol As Collection
Set xCol = oCol(Me.OpenArgs)


and read each variable you want, like

Dim var As Double
var = xCol("OneThird")



No encoding required, and you can even pass complex objects (which may not
be easy to convert to string, or back from string)


Vanderghast, Access MVP


Hunter57 via AccessMonster.com said:
Hi dch3,

I develop Access Database Applications, SQL Server, and ASP.Net Web
Applications. So I am quite familiar with the QueryStrings of which you
speak.

Now I think I am understanding part of what you are doing. I do not yet
understand all that you have written but I think I understand what you are
doing with the OpenArgs. It sounds like you are using a sub or two to set
properties and values of your Reports, such as the Title and RecordSource,
when certain values are passed to the Report using OpenArgs.

You may be using the Split Function to create an Array from the OpenArgs,
which is a very nice way to handle multiple values passed in an OpenArgs
String.

I think you have a good idea there and there are a lot of interesting
opportunities with that approach.

What is confusing us, I think, is dealing with both the DoCmd.OpenReport
parameters and the OpenArgs. I would like to hear some more about what
you
are doing to gain a better understanding.

Best Regards,
Pat
http;//gainingaccess.com

Each form/report using OpenArgs will have their own sub which will contain
any additional code needed to manipulate the form/report on the calling
side
as in the example below. It might very well be that the sub contains a
single
statement, but it will streamline things in the event that the same basic
code needs to be executed before and/or after the DoCmd statement.

Sub openfrmOrders(Optional strWHEREStatement as String, Optional
[parameter1] as string, Optional [parameter2] as String...)

[Any relevant code...]

DoCmd.OpenReport ..., strWHEREStatement, ... , "open args string"

[Any relevant code...]

end sub
Form/Report that takes .OpenArgs so that the assorted parameters show
up via
Intelisense along the lines of ...
[quoted text clipped - 32 lines]
and back to the point, all of the forms/reports hand their own
.OpenArgs the
same way.
 
D

dch3

See Below

AccessVandal via AccessMonster.com said:
The openargs is to filter the form’s record source.
The OpenArgs parameter is an arbitrary string by which information can be
passed into a Form or Report. The value is accessed by the .OpenArgs property
of the form or object as in Me!OpenArgs. The FILTER or WHERE parameter of
the .OpenForm or .OpenReport methods of the DoCmd object manipulate the
results being returned.
http://msdn.microsoft.com/en-us/library/aa220276(office.11).aspx
http://msdn.microsoft.com/en-us/library/aa160845.aspx
What you have said is very confusing, you’re already manipulating the
openargs string from somewhere.
The OpenArgs parameter is just one of the PARAMETERS used (or not used) to
open the form or report.
Are you saying … manipulate string in Form1 to open Form2 then manipulate
string in Form2 to Open Form3 or Report? Or it’s something else? Keeping the
original openargs in Form2 in Form3 then return original openargs to Form2?

All I'm saying is - build a string with multiple parameters (either required
or optional) and pass it to the form using the OpenArgs PARAMETER and the
extract it. The OpenArgs PARAMETER only takes a string - hence if you're
working with multiple values in the string you have to extract them. If the
string is "David Holley" while you know the name, you don't know the first or
last name without working with the string. If the string is
"firstName=David;lastname=Holley", you extract both the first and last names.

Don't think in terms of whats doing what to what - just that there's
information that the Form/Report needs which is being passed to it via
OpenArgs. Whether or not the Form / Report contains the code to extract the
information is irrelevant. It might be present in the code or it might be in
an external SUB to allow for reuse. I'm using the later.

This all does pertain to my original post, but I'm not going to elaborate
further here for now.
Here a link for class module.

http://support.microsoft.com/kb/209968/en-us

http://support.microsoft.com/kb/198465/en-us

Else I don’t have a clue at all.

Each form/report using OpenArgs will have their own sub which will contain
any additional code needed to manipulate the form/report on the calling side
as in the example below. It might very well be that the sub contains a single
statement, but it will streamline things in the event that the same basic
code needs to be executed before and/or after the DoCmd statement.

Sub openfrmOrders(Optional strWHEREStatement as String, Optional
[parameter1] as string, Optional [parameter2] as String...)

[Any relevant code...]

DoCmd.OpenReport ..., strWHEREStatement, ... , "open args string"

[Any relevant code...]

end sub
 
D

dch3

Hunter57 via AccessMonster.com said:
Hi dch3,

I develop Access Database Applications, SQL Server, and ASP.Net Web
Applications. So I am quite familiar with the QueryStrings of which you
speak.

Now I think I am understanding part of what you are doing. I do not yet
understand all that you have written but I think I understand what you are
doing with the OpenArgs. It sounds like you are using a sub or two to set
properties and values of your Reports, such as the Title and RecordSource,
when certain values are passed to the Report using OpenArgs.
Yes. An external sub extracts the information from the OpenArgs string and
then loads up a global array for use when the information is needed. If this
were ASP, it'd just be a matter of refering to the QueryString collection of
the Request object.
You may be using the Split Function to create an Array from the OpenArgs,
which is a very nice way to handle multiple values passed in an OpenArgs
String.
Yes. Actually, I'm Spliting twice - first to extracted the parameter pair
and a second time to extract the parameter name and parameter value. The
string is formated as in
"parameter1Name=parameter1value;parameter2Name=parameter2value;parameter3Name=parameter3value"
I think you have a good idea there and there are a lot of interesting
opportunities with that approach.

What is confusing us, I think, is dealing with both the DoCmd.OpenReport
parameters and the OpenArgs. I would like to hear some more about what you
are doing to gain a better understanding.
It all comes down to reusing the same report object to provide different
information. Lets say that you have a report that shows Nationwide sides by
region by branch by sales person. Running the report as is provides ALL of
that information, but the sales person just wants their stuff or a regional
VP wants his/her region only. Obviously, you'll pass in a specific WHERE
statement to filter the records. But what if you want to just show TOTALS as
opposed to the detail. By manipulating the sections being printed you can
narrow down the content - just show sub totals or totals - all without
creating a whole new report. Naturally, you'll want to change the report
title. I'm using OpenArgs to do just that. In the end only one Access report,
but on the user side mutliple reports.
Best Regards,
Pat
http;//gainingaccess.com

Each form/report using OpenArgs will have their own sub which will contain
any additional code needed to manipulate the form/report on the calling side
as in the example below. It might very well be that the sub contains a single
statement, but it will streamline things in the event that the same basic
code needs to be executed before and/or after the DoCmd statement.

Sub openfrmOrders(Optional strWHEREStatement as String, Optional
[parameter1] as string, Optional [parameter2] as String...)

[Any relevant code...]

DoCmd.OpenReport ..., strWHEREStatement, ... , "open args string"

[Any relevant code...]

end sub
Form/Report that takes .OpenArgs so that the assorted parameters show up via
Intelisense along the lines of ...
[quoted text clipped - 32 lines]
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.
 
D

dch3

See my post right above this.

Michel Walsh said:
Using Split could be fine, but that assumes you may have to encode your data
to strings.

Another solution is to use a collection of collections. Have a first
collection, global to the whole application, let us call it oCol.

Next, define all the arguments you want to pass inside a collection:

Dim mCol As New Collection
mCol.Add 33, "zozo"
mCol.Add Now(), "when"
mCol.Add 1 / 3, "oneThird"

here, 3 arguments, zozo, when, and oneThird are added to mCol.


Add the collection to oCol:


If oCol Is Nothing Then Set oCol = New Collection

oCol.Add mCol, "Report1"



And use the name you supplied, in oCol, for your collection as OpenArgs:


DoCmd.OpenReport "Report1", OpenArgs:="Report1"


You can then, inside the report, use:


Dim xCol As Collection
Set xCol = oCol(Me.OpenArgs)


and read each variable you want, like

Dim var As Double
var = xCol("OneThird")



No encoding required, and you can even pass complex objects (which may not
be easy to convert to string, or back from string)


Vanderghast, Access MVP


Hunter57 via AccessMonster.com said:
Hi dch3,

I develop Access Database Applications, SQL Server, and ASP.Net Web
Applications. So I am quite familiar with the QueryStrings of which you
speak.

Now I think I am understanding part of what you are doing. I do not yet
understand all that you have written but I think I understand what you are
doing with the OpenArgs. It sounds like you are using a sub or two to set
properties and values of your Reports, such as the Title and RecordSource,
when certain values are passed to the Report using OpenArgs.

You may be using the Split Function to create an Array from the OpenArgs,
which is a very nice way to handle multiple values passed in an OpenArgs
String.

I think you have a good idea there and there are a lot of interesting
opportunities with that approach.

What is confusing us, I think, is dealing with both the DoCmd.OpenReport
parameters and the OpenArgs. I would like to hear some more about what
you
are doing to gain a better understanding.

Best Regards,
Pat
http;//gainingaccess.com

Each form/report using OpenArgs will have their own sub which will contain
any additional code needed to manipulate the form/report on the calling
side
as in the example below. It might very well be that the sub contains a
single
statement, but it will streamline things in the event that the same basic
code needs to be executed before and/or after the DoCmd statement.

Sub openfrmOrders(Optional strWHEREStatement as String, Optional
[parameter1] as string, Optional [parameter2] as String...)

[Any relevant code...]

DoCmd.OpenReport ..., strWHEREStatement, ... , "open args string"

[Any relevant code...]

end sub

Form/Report that takes .OpenArgs so that the assorted parameters show
up via
Intelisense along the lines of ...
[quoted text clipped - 32 lines]
and back to the point, all of the forms/reports hand their own
.OpenArgs the
same way.
 
D

dch3

Yes. I now have a sub that explicity opens the report as in

Sub openRptLoadListDetail(Optional intView as Integer , Optional
strWhereStatement, Optional strReportTitle as String, Optional
strLoadListInformation as String)

[Code which builds the string for the open args - it only passes in a value
if a value was passed to here]

DoCmd.OpenReport [parameters]

end

Hunter57 via AccessMonster.com said:
Hi dch3,

A few posts back you seemed to indicate that you were passing values to a Sub
which then used DoCmd to Open the Report.

Are you using one sub to modify the WhereCondition & OpenArgs strings
*before* it they used as a DoCmd.OpenReport Parameter and then another sub to
use OpenArgs after the Report's On Open Event fires?

Best Regards,
Pat
[quoted text clipped - 7 lines]
properties and values of your Reports, such as the Title and RecordSource,
when certain values are passed to the Report using OpenArgs.
Yes. An external sub extracts the information from the OpenArgs string and
then loads up a global array for use when the information is needed. If this
were ASP, it'd just be a matter of refering to the QueryString collection of
the Request object.
You may be using the Split Function to create an Array from the OpenArgs,
which is a very nice way to handle multiple values passed in an OpenArgs
String.
Yes. Actually, I'm Spliting twice - first to extracted the parameter pair
and a second time to extract the parameter name and parameter value. The
string is formated as in
"parameter1Name=parameter1value;parameter2Name=parameter2value;parameter3Name=parameter3value"
I think you have a good idea there and there are a lot of interesting
opportunities with that approach.

What is confusing us, I think, is dealing with both the DoCmd.OpenReport
parameters and the OpenArgs. I would like to hear some more about what you
are doing to gain a better understanding.
It all comes down to reusing the same report object to provide different
information. Lets say that you have a report that shows Nationwide sides by
region by branch by sales person. Running the report as is provides ALL of
that information, but the sales person just wants their stuff or a regional
VP wants his/her region only. Obviously, you'll pass in a specific WHERE
statement to filter the records. But what if you want to just show TOTALS as
opposed to the detail. By manipulating the sections being printed you can
narrow down the content - just show sub totals or totals - all without
creating a whole new report. Naturally, you'll want to change the report
title. I'm using OpenArgs to do just that. In the end only one Access report,
but on the user side mutliple reports.
Best Regards,
Pat
[quoted text clipped - 22 lines]
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.

--
Hunter 57
http://churchmanagementsoftware.googlepages.com/home

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-modules/200809/1
 
D

dch3

Now that we've chased, killed, skinned and sold the rabbit on EBAY...

Here are the assorted subs..

[External Module]
Option Compare Database
Option Explicit

'Provide a global array to store the OpenArgs parameter names & values for
easy retrieval
Global aOpenParameters()

Sub openRptLoadListDetail(Optional strView As String, Optional
strWhereStatement As String, Optional strReportTitle As String, Optional
strLoadListInformation As String)

'Encapsulate opening the report so that OpenArgs string is built as needed
and passed in, this way, we don't have to remember what the parameter names
are as we code AND we centralize all code that opens the report.

Dim strOpenArgs As String

If Len(strReportTitle) > 0 Then strOpenArgs = strOpenArgs &
"mReportTitle=" & strReportTitle

If Len(strReportTitle) > 0 And Len(strLoadListInformation) > 0 Then
strOpenArgs = strOpenArgs & ";"

If Len(strLoadListInformation) > 0 Then strOpenArgs = strOpenArgs &
"mLoadListInformation=" & strLoadListInformation

DoCmd.OpenReport "rptLoadList_Detail", strView, , strWhereStatement, ,
strOpenArgs

End Sub

Sub loadParametersArray(strArgs As Variant)

'Parse out the OpenArgs string for a Form/Report

'Break the string using ";" as the delimiter
Dim aOpenArgs
'Break the substrings using "=" as the delimiter
Dim aOpenArgsDetail
Dim i As Integer
Dim intNumberOfParameters As Integer
'Temp variable to work w/OpenArgs, charactersInString was giving a ByVal
error which couldn't be worked around, charactersInString() is a function that
counts the number of occurances of a specific character in a string, of
course I could use UBound to calculate the number of parameters but didn't
think about that at the time, I'll probably switch over to that approach

Dim strArgsWorkVar As String

If IsNull(strArgs) = False Then
'Break apart the string into the individual parameter Name/Value pairs
aOpenArgs = Split(strArgs, ";")
strArgsWorkVar = strArgs
intNumberOfParameters = charactersInString(";", strArgsWorkVar) + 1
If intNumberOfParameters > 0 Then
ReDim aOpenParameters(intNumberOfParameters, 2)
'Break apart the parameter Name/Value pairs and load up the global
'array
For i = 0 To intNumberOfParameters - 1
aOpenArgsDetail = Split(aOpenArgs(i), "=")
aOpenParameters(i, 0) = aOpenArgsDetail(0)
aOpenParameters(i, 1) = aOpenArgsDetail(1)
Next i
End If
End If

End Sub

Function getParameterVariable(strParameter As String) As Variant
'Loop through the global array to look up the value for the named
parameter,
Dim i As Integer

getParameterVariable = Null

Select Case UBound(aOpenParameters, 1)
Case -1
Case Is > 0
While i <= UBound(aOpenParameters, 1) - 1 And
IsNull(getParameterVariable)
If aOpenParameters(i, 0) = strParameter Then
getParameterVariable = (aOpenParameters(i, 1))
i = i + 1
Wend
Case Else
End Select

End Function

In the report...
Option Compare Database
Option Explicit
Dim mReportTitle As String
Dim mLoadListInformation As String

Private Sub Report_Open(Cancel As Integer)

If IsNull(Me.OpenArgs) = False Then
'Load up the array
Call loadParametersArray(Me.OpenArgs)
'Load up the report specific module-level variables, this allows
loadParametersArray and getParameterVariable to be reused for *ANY* form or
report
'Explicity cast the variable since it non-strings will be passed in
as a string
mReportTitle = CStr(getParameterVariable("mReportTitle"))
mLoadListInformation =
CStr(getParameterVariable("mLoadListInformation"))
'Set the report title and subheader information
If mReportTitle <> "" Then Me.lblReportTitle.Caption = mReportTitle
'The Load List Information control's control source is a calculated
value of two values in the recordsource. My primary need for starting all of
this was to be able to run the report using a different WHERE statement that
returns a broader range of values - Example - If you're working with a report
that merely provides the detail of an Order, you might use "OrderId = 5" to
view all the items on order number 5, but if you use "ClientId = 300" you'd
return all of the items ordered by client number 300. You'd certainly want to
state that using "<All Orders>" as opposed to "Order #5".
If mLoadListInformation <> "" Then
Me!exprLoadListInformation.ControlSource = "=" & Chr(34) &
mLoadListInformation & Chr(34)
End If

End Sub

dch3 said:
I asked this question differently in another post and got an answer that
didn't answer the question...

So is it possible to create a function that takes a parameter which
represents a global variable and in the function set the variable? Basically
I want a function whereby I can pass in a variable NAME and have the function
set the variable.

NOTE: YES, YES, YES! I am fully aware that I could explicitly set the
variable (mySystemName = "Hello World"), *BUT* I want a function that is
generic and can be used regardless of the variable name that needs to be set.
The function will be used in conjunction with the .OpenArgs statement of the
.OpenForm and .OpenReport methods of DoCmd.

As in...

call setGlobalVariable("mySystemName", "Hello World") will set the global
variable mySystemName to "Hello World"

Global mySystemName as Variant
Global myNetworkName as Variant

sub setGlobalVariable (strVariableName as String, varValue as Variant)

[statement which recognizes strVariableName as a DIM'd variable] = varValue

end sub
 
M

Michel Walsh

It can be used where you have more than one parameter to send to your VBA
code behind the form/report and you don't want to relay on global variable
for each of those parameter, and/or when the value to string MAY be a
problem like a double value being truncated to just few decimal when
formatted to a string, or may even be formatted as what your prorgam will
read back as two integers delimited by a coma, if the default regional
setting is using a coma, rather than a dot, as decimal delimiter, to
'encode' the double number into a string. As example, in some European
countries, you can get:

? 5 / 2

2,5


which MAY be read back as two integers rather than a single float.

Using the collection avoid those conversions.


Sure, there is the global variable oCol, but that one is unlikely to collide
with another one of the same name, having a totally different use.



Vanderghast, Access MVP



Hunter57 via AccessMonster.com said:
Hi Michel,

That is some very useful information that I look forward to using. Thank
you.


Can you tell me what are some of the possible uses of the collection data
in
the Report or Form?

Best Regards
Pat Wood
http://gainingaccess.com

Michel said:
Using Split could be fine, but that assumes you may have to encode your
data
to strings.

Another solution is to use a collection of collections. Have a first
collection, global to the whole application, let us call it oCol.

Next, define all the arguments you want to pass inside a collection:

Dim mCol As New Collection
mCol.Add 33, "zozo"
mCol.Add Now(), "when"
mCol.Add 1 / 3, "oneThird"

here, 3 arguments, zozo, when, and oneThird are added to mCol.

Add the collection to oCol:

If oCol Is Nothing Then Set oCol = New Collection

oCol.Add mCol, "Report1"

And use the name you supplied, in oCol, for your collection as OpenArgs:

DoCmd.OpenReport "Report1", OpenArgs:="Report1"

You can then, inside the report, use:

Dim xCol As Collection
Set xCol = oCol(Me.OpenArgs)

and read each variable you want, like

Dim var As Double
var = xCol("OneThird")

No encoding required, and you can even pass complex objects (which may not
be easy to convert to string, or back from string)

Vanderghast, Access MVP
[quoted text clipped - 50 lines]
.OpenArgs the
same way.
 
D

dch3

Another prime reason for encapsulating the .OpenReport is that over the
weekend I realized that running a report isn't just running a report. Is the
report just going to be previewed (save a tree)? Is it going to be printed
direct to printer? Is it going to be outputted to a snapshot or other file
type? Or is the data going to be exported to Excel in a generic format for
use by the user?

Encapsulation puts all of that logic and code into a single Sub for use
throughout the database - and yes, the reports can be run from a variety of
points in the the app.

dch3 said:
Yes. I now have a sub that explicity opens the report as in

Sub openRptLoadListDetail(Optional intView as Integer , Optional
strWhereStatement, Optional strReportTitle as String, Optional
strLoadListInformation as String)

[Code which builds the string for the open args - it only passes in a value
if a value was passed to here]

DoCmd.OpenReport [parameters]

end

Hunter57 via AccessMonster.com said:
Hi dch3,

A few posts back you seemed to indicate that you were passing values to a Sub
which then used DoCmd to Open the Report.

Are you using one sub to modify the WhereCondition & OpenArgs strings
*before* it they used as a DoCmd.OpenReport Parameter and then another sub to
use OpenArgs after the Report's On Open Event fires?

Best Regards,
Pat
Hi dch3,

[quoted text clipped - 7 lines]
properties and values of your Reports, such as the Title and RecordSource,
when certain values are passed to the Report using OpenArgs.
Yes. An external sub extracts the information from the OpenArgs string and
then loads up a global array for use when the information is needed. If this
were ASP, it'd just be a matter of refering to the QueryString collection of
the Request object.

You may be using the Split Function to create an Array from the OpenArgs,
which is a very nice way to handle multiple values passed in an OpenArgs
String.
Yes. Actually, I'm Spliting twice - first to extracted the parameter pair
and a second time to extract the parameter name and parameter value. The
string is formated as in
"parameter1Name=parameter1value;parameter2Name=parameter2value;parameter3Name=parameter3value"

I think you have a good idea there and there are a lot of interesting
opportunities with that approach.

What is confusing us, I think, is dealing with both the DoCmd.OpenReport
parameters and the OpenArgs. I would like to hear some more about what you
are doing to gain a better understanding.
It all comes down to reusing the same report object to provide different
information. Lets say that you have a report that shows Nationwide sides by
region by branch by sales person. Running the report as is provides ALL of
that information, but the sales person just wants their stuff or a regional
VP wants his/her region only. Obviously, you'll pass in a specific WHERE
statement to filter the records. But what if you want to just show TOTALS as
opposed to the detail. By manipulating the sections being printed you can
narrow down the content - just show sub totals or totals - all without
creating a whole new report. Naturally, you'll want to change the report
title. I'm using OpenArgs to do just that. In the end only one Access report,
but on the user side mutliple reports.

Best Regards,
Pat
[quoted text clipped - 22 lines]
and back to the point, all of the forms/reports hand their own .OpenArgs the
same way.

--
Hunter 57
http://churchmanagementsoftware.googlepages.com/home

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-modules/200809/1
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top