Pass a variable to another form

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello

I have two forms, on frm1 I have the variable Public mytx as String, I want to use this variable to populate a textbox on frn
such as Me.Text1 = frm.mytx
However, when I do this, I get an object required error. Please Help. Thanks
 
Tom,

If (from Form1) you are copying the value of mytx from Form1 to Form2, use
the following syntax:
Forms!Form2!Text1 = mytx

If (from Form1) you are copying the value of mytx from Form2 to Form1, use
the following syntax:
Me!Text1 = Form_Form2.mytx

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html


Tom said:
Hello,

I have two forms, on frm1 I have the variable Public mytx as String, I
Click to expand...
want to use this variable to populate a textbox on frn2
such as Me.Text1 = frm.mytxt
However, when I do this, I get an object required error. Please Help.
Click to expand...
Thanks
 
To pass a "variable" you would need to have it as a "global" variable. This
would make it available anywhere within the project. There are other ways to
handle this though. You can then refer to the control on the first form, if
the first form is open.

Example:
Me.Text1 = Forms!frm1!txtMyTextbox

Another way to pass the value is to use the OpenArgs argument in the
DoCmd.OpenForm call. The value is a string, but you can convert it to/from a
string as needed.

Example:
DoCmd.OpenForm "frm2",,,,,, mytx
In Load event of frm2:
Me.Text1 = Me.OpenArgs

To continue with the variable as a Public variable and refer to it that way,
declare the variable in the Declarations section of the module then you can
simply refer to it any time you want.

Option Compare Database
Option Explicit 'if this isn't here, it should be
Public mytx As String

'Subs go here

Then to refer to it elsewhere in you project:
Me.Text1 = mytx

If you do this, it will work if you declare it in the form's module, but
since these types of variables are available "globally" throughout the
project, they are normally declared in the Declarations section of a
standard module (a module in the Modules tab of the main database window).

--
Wayne Morgan
Microsoft Access MVP


Tom said:
Hello,

I have two forms, on frm1 I have the variable Public mytx as String, I
Click to expand...
want to use this variable to populate a textbox on frn2
such as Me.Text1 = frm.mytxt
However, when I do this, I get an object required error. Please Help.
Click to expand...
Thanks
 
Ok, Thanks....

Actually my fom names have spaces in them such as Data Input Form, so I had to wrap the form names in brackets, th
strange thing is that Me.Txt1 = Forms![Data Input Form]!mytx would not work, bu
Me.Txt1 = Forms![Data Input Form].mytx does work. The only difference is the "." before the variable rather then a " ! "

Is there a rule of thumb on when to use the ! or the .

Thanks
 
Tom,

<<...Me.Txt1 = Forms![Data Input Form]!mytx would not work...>>
My example did use ".", not "!".

The Bang operator ( ! ) usually refers to a control, field or object in a
collection, for example, an instance of a control in a form's Controls
collection.

The Dot operator ( . ) usually refers to an object's methods or properties,
for example, Forms!Form1!Control1.Enabled, or rst.MoveNext.

In this case, the Dot operator works (whereas the Bang operator does not)
because the variable mytx is not an object that belongs to a collection, so
it's treated the same way as properties and methods of the form.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html


Tom said:
Ok, Thanks.....

Actually my fom names have spaces in them such as Data Input Form, so I
Click to expand...
had to wrap the form names in brackets, the
strange thing is that Me.Txt1 = Forms![Data Input Form]!mytx would not work, but
Me.Txt1 = Forms![Data Input Form].mytx does work. The only difference is
Click to expand...
the "." before the variable rather then a " ! " ?
 
hey, that's a neat trick! i always thought you could only use form level
variables in their own form. am i right in thinking that you can only refer
to Forms!MyForm.myformvariable (in another form) as long as MyForm is open?


Graham R Seach said:
Tom,

<<...Me.Txt1 = Forms![Data Input Form]!mytx would not work...>>
My example did use ".", not "!".

The Bang operator ( ! ) usually refers to a control, field or object in a
collection, for example, an instance of a control in a form's Controls
collection.

The Dot operator ( . ) usually refers to an object's methods or properties,
for example, Forms!Form1!Control1.Enabled, or rst.MoveNext.

In this case, the Dot operator works (whereas the Bang operator does not)
because the variable mytx is not an object that belongs to a collection, so
it's treated the same way as properties and methods of the form.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html


Tom said:
Ok, Thanks.....

Actually my fom names have spaces in them such as Data Input Form, so I
Click to expand...
had to wrap the form names in brackets, the
strange thing is that Me.Txt1 = Forms![Data Input Form]!mytx would not work, but
Me.Txt1 = Forms![Data Input Form].mytx does work. The only difference
Click to expand...
is
the "." before the variable rather then a " ! " ?
Is there a rule of thumb on when to use the ! or the . ?

Thanks
Click to expand...
Click to expand...
 
tina said:
hey, that's a neat trick! i always thought you could only use form
level variables in their own form. am i right in thinking that you
can only refer to Forms!MyForm.myformvariable (in another form) as
long as MyForm is open?
Click to expand...

Yes, and myformvariable must be declared Public, at the module level.
 
so, as Wayne's post said, once i declare the form level variable as Public,
it is availabe anywhere in the project. got it.
so the only difference between a Public variable in a form and a Public
variable in a standard module (which i have used), is in their life span? as
in: the form's Public variable is available while the form is open, and
does not hold a value after it is closed, while the standard module's Public
variable is available as long as the "session" lasts, and holds it's
assigned value for the life of the session?
sorry so wordy, just want to be sure i have a clear understanding. :)
 
tina said:
so, as Wayne's post said, once i declare the form level variable as
Public, it is availabe anywhere in the project. got it.
so the only difference between a Public variable in a form and a
Public variable in a standard module (which i have used), is in their
life span? as in: the form's Public variable is available while the
form is open, and does not hold a value after it is closed, while the
standard module's Public variable is available as long as the
"session" lasts, and holds it's assigned value for the life of the
session?
sorry so wordy, just want to be sure i have a clear understanding. :)
Click to expand...

Right, although it's worth being aware that public variables will lose
their values if something -- an unhandled error, for example -- causes
the VB project to be reset. At least, I know this is true for public
variables in a standard module; I can't swear that it is true for
public variables in form modules, but I would be surprised if it weren't
so.
 
tina said:
so, as Wayne's post said, once i declare the form level variable as Public,
it is availabe anywhere in the project. got it.
so the only difference between a Public variable in a form and a Public
variable in a standard module (which i have used), is in their life span? as
in: the form's Public variable is available while the form is open, and
does not hold a value after it is closed, while the standard module's Public
variable is available as long as the "session" lasts, and holds it's
assigned value for the life of the session?
sorry so wordy, just want to be sure i have a clear understanding. :)
Click to expand...


Just to add to my 2 cents worth to this discussion.

There is a big difference between Public variables in a form
(actually a class) object's module and those in a standard
module. In a class module, the Public variables are
properties of the class and, therefore, follow the rules of
properties.

You don't really need to know all that until you get into
class objects more deeply, but it might help to keep them
separate when you think about what's really going on.
 
public variables will lose
their values if something -- an unhandled error, for example -- causes
the VB project to be reset.
Click to expand...

okay, how do i know if the project is reset? is it an automatic thing? i
mean, if i get an error while running code, does the VB project always reset
at that time? and if i use standard error handling with the On Error GoTo,
and a msgbox with the error# and description, and a Resume to the Exit part
of my handler, is the error then considered "handled" by Access?
again, sorry so wordy, just want to understand this. maybe you could
recommend some reading i should do - i know you don't want to write me a
book! :)
 
thank you, Marshall! classes objects are exactly the what i'm planning to
learn about next, so that info is very helpful to me - perfect timing! :)
 
tina said:
okay, how do i know if the project is reset? is it an automatic
thing? i mean, if i get an error while running code, does the VB
project always reset at that time? and if i use standard error
handling with the On Error GoTo, and a msgbox with the error# and
description, and a Resume to the Exit part of my handler, is the
error then considered "handled" by Access?
again, sorry so wordy, just want to understand this. maybe you could
recommend some reading i should do - i know you don't want to write
me a book! :)
Click to expand...

I am not an expert on this, but as I understand it, the only time the
error is considered "unhandled" is when Access displays its default
error dialog. If there's an On Error statement in effect, whether it's
"On Error Resume ..." or "On Error GoTo ..." (except "GoTo 0"), that
error would be considered "handled".

The _Access <version> Deveoper's Handbook_ from Sybex has a fairly
extensive chapter on error-handling.
 
Back
Top