How to copy value of textbox of one form to textbox of another form

spard

New member
Local time
Today, 13:55
Joined
Apr 2, 2010
Messages
4
HI,
Actually i have one form name Report and it have textbox name reportID.I want to copy the value of reportID textbox to textbox named AssociatedImageID of second form named AssociatedImage when check box of second form is checked.

So can you please help me by providing me code for this problem.
Thank You.
 
spard,

Take a look at the OpenArgs argument when opening a form. You can pass the Id value you want to pass to the next form using the OpenArgs method. This is part of the arguments that are allowed when you use the Docmd.openform method.

You can then use VBA code in the On Current event of the second form to write the Id value to any text box you wish.
 
spard,

Take a look at the OpenArgs argument when opening a form. You can pass the Id value you want to pass to the next form using the OpenArgs method. This is part of the arguments that are allowed when you use the Docmd.openform method.

You can then use VBA code in the On Current event of the second form to write the Id value to any text box you wish.

Hi

ive heard & read good & bad about openargs. personally, i always prefer a public variable to pass values. at least you can then use it continually or call the same function to hold the value in question.


nidge
 
What can possibally be bad about using a parameter with a builtin Access method? This is native functionality. While there are plenty of reasons for declaring and using Public variables, this is not one of them. There is no reason for declaring public variables for this as it simply uses resources that are not necessary when there is a native method for handling it.
 
Hi

there are a few native items that are not best used in access. Macros for one. While some programmers swear by them, other detest them so not all native items are worth.

I for one prefer variables and find them more controllable and easy to set up. You can always empty the variable after use to prevent memory loss though I can see a re-useable variable would create that much of a lag in memory afterall, the op was only looking for a simple transfer of a textbox data to another form.

If the second form was opened before the first, the op could always just use the simple method of setting the value based on the other form. You have to consider that an op asking questions may not be as experienced as others thus might get confused on a more complex method especially if that method is not always used. In my opinion, keeping things simple and more constant is a key thing and if you're using very similar methods daily, it would be easier to remember.

In my opinion anyway:)

Nidge
 
there are a few native items that are not best used in access. Macros for one. While some programmers swear by them, other detest them so not all native items are worth.
Just because you happen not to like macros and prefer not to use them does not have any relavance to deciding if they should be used in Access. If they were not good to be used in Access don't you think that Microsoft would have removed them by now? Not to mention that they are going to be an even more intrecrate part of the entire process with Access 2010.

the op was only looking for a simple transfer of a textbox data to another form.
And I proposed at least one method for doing exactly what the OP asked for, and without causing any additional overhead.

If the second form was opened before the first, the op could always just use the simple method of setting the value based on the other form.
If the second form was being opened first that would be nothing in the first for to reference. This makes no sense and is totally out of scope for what the OP asked for.

others thus might get confused on a more complex method especially if that method is not always used
There is nothing "complex" about providing paramenters when using built-in methods.

In my opinion, keeping things simple and more constant is a key thing and if you're using very similar methods daily, it would be easier to remember.

In my opinion anyway
Nothing about passing information to another form using the OpenArg parameter when opening the second form is difficult. Although you may not use this method, believe me, there are plenty of Access develeopers who do.

To the OP:
Plase do your own research into this and use the metod that best accomplishes the desired goal. Thankfully there are always multiple ways to accomplish the same end result. You have been told of at least two methods for do the same task and there are even other ways that have not been even mentioned here.

Please do not let this exchange of diverse opinions detur you from you goal.

Good luck with your project.
 
HI Mr B,
Thanks for your suggestion.I did as u mention but when my chekcbox is clicked the always 0 value is assign instead of value in ID of first form.My code is like this on second form:

Private Sub Form_Current()
Dim i As Integer
If Check6 = True Then
If Not IsNull(Me.OpenArgs) Then
i = Me.OpenArgs
Me.txtbox_Id= i
End If
End If
End Sub

I write code like this in first form:

Private Sub Form_Open(Cancel As Integer)
DoCmd.OpenForm "AssociatedImage", , , Me.txtbox_ID
End Sub

The type of txtbox_ID is integerCan u tell me what is wrong with this code.
Thank You..
 
HI Mr B,
Thanks for your suggestion.I did as u mention but when my chekcbox is clicked the always 0 value is assign instead of value in ID of first form.My code is like this on second form:

Private Sub Form_Current()
Dim i As Integer
If Check6 = True Then
If Not IsNull(Me.OpenArgs) Then
i = Me.OpenArgs
Me.txtbox_Id= i
End If
End If
End Sub

I write code like this in first form:

Private Sub Form_Open(Cancel As Integer)
DoCmd.OpenForm "AssociatedImage", , , Me.txtbox_ID
End Sub

The type of txtbox_ID is integerCan u tell me what is wrong with this code.
Thank You..

What is the value that is in Me.txtbox_Id on form one when you pass the value to the second form? Make sure there is a value there.

Then try this code:

Code:
Private Sub Form_Current()
Dim i As Long
If Check6 = True Then
     'here you can just check to see if the value is > zero
     If Me.OpenArgs > 0 Then
          'you may be using the code below to check the value in OpenArgs
          'i = Me.OpenArgs
          'Me.txtbox_Id= i
 
          'you could just do 
          me.txtbox_ID = me.openargs
     End If
End If
End Sub
 
Just adding to what Mr. B provided you with. He may have just missed out the Len() function:

Code:
If Len(Me.OpenArgs) = 0 Then
 
There is a bigger problem with using Public Variables. They can become undefined spontaneously after an untrapped error. If you are in a case where you have three layers (say, an opening switchboard form, a form opened from the switchboard, and a form opened from the second form), and if something goes haywire on the switchboard, you can suddenly find that any publics on the switchboard have become de-instantiated. Depending on other things that are going on, you might have notifications suppressed just enough to not know about this until you exit the second form.

Learned that one painfully a few months ago.
 
That's very true The Doc Man. This happens when the variable is declared as public in the Object's module (i.e. a form's module for example) or an instance of the public variable (declared within a Module) is instantiated in the Object's module.

However, I haven't seen a case where a variable declared in a Module (and not instantiated outside of the module) gets de-instantiated following an un-trapabble error.
 
However, you won't lose your global variables with an untrapped error if the database is compiled to an MDE or ACCDE file. (Albert D. Kallal taught me that one)
 
He may have, I don't remember seeing any explanation, just that it is what it is (and I verified what he said).
 
It could be the way resources are allocated and referred to in those versions. Good point SOS.
 

Users who are viewing this thread

Back
Top Bottom