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!

  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.

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.