Opening a form with 'openargs'

[Susan Bricker]

Hi. I am trying to open a form using 'openargs' parameter of the
docmd.openform action. The problem is that I would like to pass the
form some character (string) and integer data. My plan was to
concatenate the data with delimeters (",") between the fields. Then in
the Form_Open( ) procedure I would parse the data and fill some "global"
variables that could be used to populate some data in the form when
there are no records (and I come up with a blank New Record). The
problem is then the integer data. Is it possible to do what I want? If
so, how?

I'm a mainframe programmer who dabbles in MS/Access and VBA for fun and
I'm trying to put together a utility that some of us here at work can
use to keep track of 'tasks' within a 'project' within a 'release of
software'. This way those of us who do 'Release Management' could
generate all the reports (and excel spreadsheets) that are asked of us.
The only problem ... I have to get it working before I show it to my
bosses.

Any suggestions? Or Questions? I'll gladly get more specific if you
need. Just ask away.

Thanks.
Sue


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Marcia]

A better way to do this might be to only pass the string via OpenArgs and then
put a multiselect listbox on your first form where the users can select the
Integer data and then pass the Integer data to the second form from the listbox.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdatasheet.com
www.pcdatasheet.com
"Susan Bricker" <sb****@att.net> wrote in message
news:40*********************@news.frii.net...

Hi. I am trying to open a form using 'openargs' parameter of the
docmd.openform action. The problem is that I would like to pass the
form some character (string) and integer data. My plan was to
concatenate the data with delimeters (",") between the fields. Then in
the Form_Open( ) procedure I would parse the data and fill some "global"
variables that could be used to populate some data in the form when
there are no records (and I come up with a blank New Record). The
problem is then the integer data. Is it possible to do what I want? If
so, how?

I'm a mainframe programmer who dabbles in MS/Access and VBA for fun and
I'm trying to put together a utility that some of us here at work can
use to keep track of 'tasks' within a 'project' within a 'release of
software'. This way those of us who do 'Release Management' could
generate all the reports (and excel spreadsheets) that are asked of us.
The only problem ... I have to get it working before I show it to my
bosses.

Any suggestions? Or Questions? I'll gladly get more specific if you
need. Just ask away.

Thanks.
Sue


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Steve Jorgensen]

OpenArgs is pretty limited. Yes, you can concatenate strings, then parse them
back out, but then there's a good chance you'll soon want more, and the string
lenght is in danger of exceeding the maximum for OpenArgs.

What I've started doing is to make a global collection variable called
gcolPassArgs. Before opening a form or report to which I want to pass
arguments, I create a colleciton of arguments, and place it in the global
variable. In Open event for the form or report, grab the collection from the
globable variable, then process its contents. It is important to fully read
the colleciton or copy it to a private reference variable in the Open event
handler since other code may rewrite the data at any time in order to pass
arguments to some other form or report.

In a standard module somewhere...

Dim gcolPassArgs As VBA.Collection

In the code that opens the form...

Dim colFormParams As VBA.Collection
Set colFormParams = New VBA.Collection
colFormParams.Add Key:="Arg1", Item:="ABCD"
colFormParams.Add Key:="Arg2", Item:=123
Set gcolPassArgs = colFormParams
DoCmd.OpenForm "frmFoo"
In frmFoo...

Private Sub Form_Open(Cancel As Integer)
Me!txtData1 = gcolPassArgs("Arg1")
Me!txtData2 = gcolPassArgs("Arg2")
End Sub
On 24 Feb 2004 18:08:41 GMT, Susan Bricker <sb****@att.net> wrote:

Hi. I am trying to open a form using 'openargs' parameter of the
docmd.openform action. The problem is that I would like to pass the
form some character (string) and integer data. My plan was to
concatenate the data with delimeters (",") between the fields. Then in
the Form_Open( ) procedure I would parse the data and fill some "global"
variables that could be used to populate some data in the form when
there are no records (and I come up with a blank New Record). The
problem is then the integer data. Is it possible to do what I want? If
so, how?

I'm a mainframe programmer who dabbles in MS/Access and VBA for fun and
I'm trying to put together a utility that some of us here at work can
use to keep track of 'tasks' within a 'project' within a 'release of
software'. This way those of us who do 'Release Management' could
generate all the reports (and excel spreadsheets) that are asked of us.
The only problem ... I have to get it working before I show it to my
bosses.

Any suggestions? Or Questions? I'll gladly get more specific if you
need. Just ask away.

Thanks.
Sue


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Bas Cost Budde]

Susan Bricker wrote:

Hi. I am trying to open a form using 'openargs' parameter of the
docmd.openform action. The problem is that I would like to pass the
form some character (string) and integer data. My plan was to
concatenate the data with delimeters (",") between the fields. Then in
the Form_Open( ) procedure I would parse the data and fill some "global"
variables that could be used to populate some data in the form when
there are no records (and I come up with a blank New Record). The
problem is then the integer data. Is it possible to do what I want? If
so, how?

I'm a mainframe programmer who dabbles in MS/Access and VBA for fun

Good practice.

Why is integer a problem? Act as if it is a string (during its OpenArgs
voyage) and then convert the string into an integer using implicit or
explicit type conversion (does implicit not work? Never mind then) See
Int() CInt() CLng()

--
Bas Cost Budde
http://www.heuveltop.org/BasCB
but the domain is nl

[Bas Cost Budde]

Susan Bricker wrote:

and Val() of course
--
Bas Cost Budde
http://www.heuveltop.org/BasCB
but the domain is nl

[Bas Cost Budde]

Steve Jorgensen wrote:

OpenArgs is pretty limited. Yes, you can concatenate strings, then parse them
back out, but then there's a good chance you'll soon want more, and the string
lenght is in danger of exceeding the maximum for OpenArgs.

What I've started doing is to make a global collection variable called
gcolPassArgs.
I even use a special table for this. Of course global variables do not
die in a normally running application, but they will die on error (some
errors?)

I think there is an article about that on my site... yes,
articles:public variables.

Before opening a form or report to which I want to pass arguments, I create a colleciton

happy to see you have the same 'type timing' as I :-)

--
Bas Cost Budde
http://www.heuveltop.org/BasCB
but the domain is nl

[Steve Jorgensen]

On Tue, 24 Feb 2004 20:04:30 +0100, Bas Cost Budde <ba*@heuveltop.org> wrote:

Steve Jorgensen wrote:

OpenArgs is pretty limited. Yes, you can concatenate strings, then parse them
back out, but then there's a good chance you'll soon want more, and the string
lenght is in danger of exceeding the maximum for OpenArgs.

What I've started doing is to make a global collection variable called
gcolPassArgs.
I even use a special table for this. Of course global variables do not
die in a normally running application, but they will die on error (some
errors?)

They die if you ever stop the code in debug mode. In this code, the global
variable is only used briefly to transfer the data from one procedure to
another, so the fragility of global data is not a big issue.

I think there is an article about that on my site... yes,
articles:public variables.

Before opening a form or report to which I want to pass

arguments, I create a colleciton

happy to see you have the same 'type timing' as I :-)

<g>

[Larry Linson]

"Steve Jorgensen" wrote

OpenArgs is pretty limited. Yes, you can
concatenate strings, then parse them
back out, but then there's a good chance
you'll soon want more, and the string
lenght is in danger of exceeding the maximum
for OpenArgs.

Strangely, perhaps, I have never come close to having to pass enough data
via OpenArgs to ever, even remotely, fear that I might one day exceed the
maximum. We must design applications differently.

Larry Linson
Microsoft Access MVP

[Steve Jorgensen]

On Thu, 26 Feb 2004 02:34:38 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:

"Steve Jorgensen" wrote

OpenArgs is pretty limited. Yes, you can
concatenate strings, then parse them
back out, but then there's a good chance
you'll soon want more, and the string
lenght is in danger of exceeding the maximum
for OpenArgs.

Strangely, perhaps, I have never come close to having to pass enough data
via OpenArgs to ever, even remotely, fear that I might one day exceed the
maximum. We must design applications differently.

Larry Linson
Microsoft Access MVP

I have, on occasion, needed to pass SQL statements to forms, and these can
easily become long. In one application, the user first enters a large amount
of data about how to translate data, moving it from one database to another,
then another form manages pre-checking the data, executing the operation, and
reporting the results. I pretty much had to make a custom class to
encapsulate the data to pass, and I had to use a global variable to pass it.

Besides all that, to me the inelegance of using a global variable to pass data
is less than the inelegance of concatenating a bunch of arguments into a
string, then parsing them back out. They're both inelegant, but the parsing
relies on more code working properly and more constraints being met to work
correctly. Regarding the string length, just because it's not exceeded during
testing, can we ensure that it won't be exceeded during production? There are
just fewer concerns to worry about with the global variable.

[Larry Linson]

I most often use OpenArgs to pass very minor amounts of data -- it never has
occurred to me to use them for user-entered information that could be
essentially unlimited in length or for passing SQL statements. So, maybe
it's just that I instinctively did NOT use OpenArgs for those, rather than
never had the need to pass anything that long.

I am of the "old school" that "has no great fear" of judiciously-used global
variables -- after all, in one or two of my programming incarnations, I
worked in eras when that's all there was for interroutine communication.
I've never seen the "horde of slavering, foaming-at-the-mouth programmers
just waiting to pounce on and corrupt a poor unprotected global" that some
seem to fear. A class for which a new object can be instantiated, or an
entry in an array of UDT's, is a good answer to the longer stuff, for those
who have seen the "Slavering Horde", though.

Larry Linson
Microsoft Access MVP
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:9g********************************@4ax.com...

On Thu, 26 Feb 2004 02:34:38 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:

"Steve Jorgensen" wrote

OpenArgs is pretty limited. Yes, you can
concatenate strings, then parse them
back out, but then there's a good chance
you'll soon want more, and the string
lenght is in danger of exceeding the maximum
for OpenArgs.
Strangely, perhaps, I have never come close to having to pass enough data
via OpenArgs to ever, even remotely, fear that I might one day exceed the
maximum. We must design applications differently.

Larry Linson
Microsoft Access MVP

I have, on occasion, needed to pass SQL statements to forms, and these can
easily become long. In one application, the user first enters a large

amount of data about how to translate data, moving it from one database to another, then another form manages pre-checking the data, executing the operation, and reporting the results. I pretty much had to make a custom class to
encapsulate the data to pass, and I had to use a global variable to pass it.
Besides all that, to me the inelegance of using a global variable to pass data is less than the inelegance of concatenating a bunch of arguments into a
string, then parsing them back out. They're both inelegant, but the parsing relies on more code working properly and more constraints being met to work correctly. Regarding the string length, just because it's not exceeded during testing, can we ensure that it won't be exceeded during production? There are just fewer concerns to worry about with the global variable.

[rkc]

"Larry Linson" <bo*****@localhost.not> wrote in message
news:9a****************@nwrddc02.gnilink.net...

I've never seen the "horde of slavering, foaming-at-the-mouth programmers
just waiting to pounce on and corrupt a poor unprotected global" that some
seem to fear. A class for which a new object can be instantiated, or an
entry in an array of UDT's, is a good answer to the longer stuff, for those who have seen the "Slavering Horde", though.

As Mr. Jorgensen has pointed out in another thread, there doesn't need to
be a horde of any kind. Just one other sane yet unaware programmer.

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:9a****************@nwrddc02.gnilink.net:

I most often use OpenArgs to pass very minor amounts of data -- it
never has occurred to me to use them for user-entered information
that could be essentially unlimited in length or for passing SQL
statements. So, maybe it's just that I instinctively did NOT use
OpenArgs for those, rather than never had the need to pass
anything that long.

I am of the "old school" that "has no great fear" of
judiciously-used global variables -- after all, in one or two of
my programming incarnations, I worked in eras when that's all
there was for interroutine communication. I've never seen the
"horde of slavering, foaming-at-the-mouth programmers just waiting
to pounce on and corrupt a poor unprotected global" that some seem
to fear. A class for which a new object can be instantiated, or an
entry in an array of UDT's, is a good answer to the longer stuff,
for those who have seen the "Slavering Horde", though.

When I get to the point where I need to pass more than one piece of
information to a form, I will tend to do one of two things:

1. create custom public properties of the form and set those after
opening the form. This works only if it's not a dialog.

2. use a class module, either as a data storage structure or as a
wrapper around the dialog itself.

I am a firm believer in writing forms that don't themselves need to
know anything about aspects outside themselves. But, obviously,
that's not always the case. This comes up mostly in my work for
cases of dialogs that are used for filtering

Of course, there's also opening the form with acHidden, putting into
it what you need, then setting its .Modal property to True, then
setting its .Visible property to True. If I were going to do that, I
think I'd probably create a public method for the form to do all of
that, as well as using my method 1) for the things you're getting
from outside.

But, mostly, compound OpenArgs indicate a design problem, in my
opinion. The worst problem is that there's no documentation of the
structure of what you have to pass it. That's why custom properties
or a class module used as a data structure is superior, because it
can validate your input. OpenArgs simply can't do that.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc