OpenArgs yawn yawn

[Starry]

I'm so bored with this! I have googled it to death.

Is anyone clued up on a OpenArgs bug? It's the same old issue that has come
and gone over the years.

Form1 has OpenArgs set to a value be it through a string variable or
directly.
The form it opens ends up with an OpenArgs null value.

No forms in design view all code stripped to basics and step tested.

Bung the same code on another machine and it works. Worst still it has
worked on this machine before!! Does anyone have a clue where the problem
lies with this I assume it is a Jet or registry issue but it's driving me
nuts again.

Cheers

 

[Starry]

I have found this......I am running 2003 so can anyone point to a file that
may be old and causing the issue (I went from 2000 to 2003)?

Additional issues that are fixed by Office XP SP3
The issues in this section are also fixed by Office XP SP3.


The OpenArgs function only works one time in a VBA project
If your Microsoft Visual Basic for Applications (VBA) code for a form makes
a call to the OpenArgs function after you open the form in design mode, you
may receive the following VBA error message:
Run-time error: 94
Invalid use of Null

 

[MikeB]

I'm so bored with this! I have googled it to death.

Is anyone clued up on a OpenArgs bug? It's the same old issue that has come
and gone over the years.

Form1 has OpenArgs set to a value be it through a string variable or
directly.
The form it opens ends up with an OpenArgs null value.

No one can tell what it is without seeing what you have rendered.

Post a cut and paste segment of the "DoCmd.OpenForm" segment with anything
relevant to the string to be used as OpenArg (isn't OpenArgs a misnomer since
it is a single string?)

 

[Starry]

Hi Mike

Apologies for the lack of info but as I said this is machine specific and is
part of a legacy db that has had no issues most of the time in the past. It
runs without issue on my other machine.

Mainform

Dim stDocName As String
Dim strOpArgs As String

stDocName = "frmContactInv"

strOpArgs = Me.InIDNumber
DoCmd.OpenForm stDocName, , , , , , strOpArgs


Secondform

Private Sub Form_Open(Cancel As Integer)
Dim strOpArgs As String

strOpArgs = Me.OpenArgs

DoCmd.GoToControl "txtInIDNumber"
DoCmd.FindRecord strOpArgs, , , , , , True

 

[Albert D. Kallal]

The OpenArgs function only works one time in a VBA project
If your Microsoft Visual Basic for Applications (VBA) code for a form
makes a call to the OpenArgs function after you open the form in design
mode, you may receive the following VBA error message:
Run-time error: 94
Invalid use of Null

I really don't understand the above? What you talking about "design mode"
here when running an application?

You can't "load", or flip a form into design mode at runtime without
disastrous results.

I would as a rule ensue a few things:

1) always use option explicit, you might have type-o's in code, or perhaps
duplicate variable names. Using option explicit will soave this.

2) turn-off, and disable track-name autocorrect.

3). Always after modifying code, go debug->compile to ensure your code
compiles, and then whack the save button.

Another really good thing to ensure more reliability is to ALWAYS distribute
the application part to your users as a mde.

And, also get rid of any references that you don't need in your application.
if there's any references for automation that use excel, word, or outlook,
change that code to use late binding. If you don't do this then you
will have nothing but problems left right and center.

I folllowed the above, and have never had an error, or problme like yours in
10+ years of deplying and setting up 100's of access applications for
clients.

Like the doctors that used to smoke cigarettes during open the surgery in
the operating room, many of them scoffed at having good discipline and
taking a serious approach to their craft.

You're gonna have to start approaching your development process in a serious
manner, and adopting the seriousness as to how you develop and do things, if
you don't, then you will have nothing but problems here.

 

[MikeB]

Hi Mike

Apologies for the lack of info but as I said this is machine specific and is
part of a legacy db that has had no issues most of the time in the past. It
runs without issue on my other machine.

Mainform

Dim stDocName As String
Dim strOpArgs As String

stDocName = "frmContactInv"

strOpArgs = Me.InIDNumber
DoCmd.OpenForm stDocName, , , , , , strOpArgs


Secondform

Private Sub Form_Open(Cancel As Integer)
Dim strOpArgs As String

strOpArgs = Me.OpenArgs

DoCmd.GoToControl "txtInIDNumber"
DoCmd.FindRecord strOpArgs, , , , , , True

One thing that seems to be common about this anomaly, is that more often
than not, it works either the first time and not the next or not the first time
but the next. Arvin describes the OpenArgs as a Global variable and as such is
vulnerable to corruption.

as unlikely as it seems, I can replicate your issue in AC2003 here, using two
simple forms (unbound) with a command button on each. The OpenArgs property of
"frmTwo" is null when the debugger is activated on the calling form "frmOne",
verified by accessing the forms collection and checking the OpenArgs property
of "frmTwo" both before and after the "DoCmd.OpenForm" in "frmOne".

Now, by calling DoCmd.OpenForm Twice as follows:

DoCmd.OpenForm "frmTwo", acPreview, , , acFormEdit, acHidden, strArgs
DoCmd.OpenForm "frmTwo", acNormal, , , , acWindowNormal

The OpenArgs property passes correctly. Following is code from each form

frmOne:

Private Sub Command0_Click()

Dim strArgs As String

strArgs = "One|Two|Three"

' the next line won't work unless the frmTwo is opened in the ide and is
present in the collection
'Forms("frmTwo").OpenArgs = ""
DoCmd.OpenForm "frmTwo", acPreview, , , acFormEdit, acHidden, strArgs
DoCmd.OpenForm "frmTwo", acNormal, , , , acWindowNormal
Debug.Print Forms("frmTwo").OpenArgs = ""

End Sub


frmTwo:

Option Compare Database
Option Explicit

Private Sub Command0_Click()
Debug.Print Me.OpenArgs
MsgBox Me.OpenArgs
End Sub

Private Sub Form_Load()
Debug.Print Me.OpenArgs
End Sub


It has been awhile, but I am sure I have used a similar tactic, opening a
form hidden, but using Propety Set in the second form in the same way it would
be done in straight VB, where the forms don't have an OpenArgs property. I
expect OpenArgs is just that under the hood somewhere.

 

[Ken Snell \(MVP\)]

One thing that seems to be common about this anomaly, is that more often
than not, it works either the first time and not the next or not the first
time
but the next. Arvin describes the OpenArgs as a Global variable and as
such is
vulnerable to corruption.

Very true... if there is any unhandled error in the program, OpenArgs will
be set to Null.

Because this is PC-specific, I would suspect that the References are messed
up on that one PC that isn't working.

 

[Starry]

Errrr.... I think the design view statement clearly caused some confusion.
Many people experiencing this issue find that is crops up when they are
developing and do not realise that they have the design view open. I was
merely stating that this was not my senario.

I will ignore the somewhat patronising coments at the end and can confirm
that I endevour to follow all the standard practices as is consummate with
12 years + of experience whilst recognising that I'm fully able to screw
things up!

 

[Starry]

Many thanks for your input Mike and Ken this is by far clearest info yet.
Spot on!

I will check through the error handling and also checkout the double call
method. I suspect that Ken may be correct regarding the references and I
will investrigate further.

 

[Albert D. Kallal]

Dim stDocName As String
Dim strOpArgs As String

stDocName = "frmContactInv"

strOpArgs = Me.InIDNumber
DoCmd.OpenForm stDocName, , , , , , strOpArgs


Secondform

Private Sub Form_Open(Cancel As Integer)
Dim strOpArgs As String

strOpArgs = Me.OpenArgs

DoCmd.GoToControl "txtInIDNumber"
DoCmd.FindRecord strOpArgs, , , , , , True

The above is going to a unreliable piece of code. You are relying on setting
the focus to particular control, and then doing a findreocrd. If the user
click a button to launch the 2nd form, what happens if he double clicks?
Then 2nd click is going to potentially *change* the focus *after* the above
code starts to run......

The result is going to be a runtime error...and loss of all variable
values.....

Furthermore, the above design is also very un-flexible, since now if other
code wants to open this form, you have code running in the on-open event
that tries to move to a particular record. And, to further nit pic this
design, the code belongs in the forms on-load event, the on-open event is
the WRONG event for this type of code....

I would suggest using the folwling code:

DoCmd.OpenForm "frmContactInv",,,"InIDNumber = " & me!InIDNumber

You not need to define *any* variables, and you NOT need any code in the 2nd
form. Thus, the 2nd form can then be used in other parts of the application,
and no on-load (or open) code need run for that 2nd form.

The above assume there is a underlying field called InIDNumber in the 2nd
forms reord source, and also assume that is a number type data field.

Relying on setting the focus to a control is not the most reliable approach
here, since as mentioned the user might click the mouse again in that time
period..and the focus may change. Furthermore, why load up a form with tons
and tons of records (and waste that bandwidth), and THEN start to search for
one particular record? I mean, you can imagine a design in which you
download all peoples names into a instant teller machine, and THEN start to
search for the persons account number? The above example uses the "where"
clause of the openform, and thus will ONLY pull the one record from the
table that we need. This is SIGNIFICANT performance advantage then scanning
the whole table using findRecord for one record. It don't make sense to load
up a form with many records, and *then* scan all that data for *one* record
we need.