OpenArgs is Null issue

Question

I am using the OpenArgs parameter to send a value when using DoCmd.OpenForm:

DoCmd.OpenForm "frmSetOther", acNormal, , , acFormAdd, acDialog, "value"

I then use Me.OpenArgs inside the opened form to grab the value. It sometimes sends a Null value instead of the original string. What is wrong?

Azarria

Answer 1

A very interesting alternative to this "openArgs" argument is to use the .properties collection of the currentProject.allforms("myFormName") object. When you need to pass a value to a form (such as a filter inherited from another control or another form, for example), just add the corresponding property for your form, and add your value to this property.

Example:

addPropertyToForm "formFilter","Tbl_myTable.myField LIKE 'A*'",myFormName

The called function will try to update the value of the "formFilter" property of the object. If the property does not exist (err 2455 is raised), it will be added as a new property in the error management code.

Function addPropertyToForm(_ 
    x_propertyName as string, _
    x_value As Variant, _
    x_formName As String) 
As Boolean

On Error GoTo errManager
CurrentProject.AllForms(x_formName).Properties(x_propertyName).Value = x_value
addPropertyToForm = True
On Error GoTo 0

Exit Function

errManager:
If Err.Number = 2455 Then
    CurrentProject.AllForms(x_formName).Properties.Add x_propertyName, Nz(x_value)
    Resume Next
Else
    msgbox err.number & ". The property " & x_propertyName & "was not created"
End If

End Function 

Lauter

+1, because it allows an OpenArgs-like functionality with instructions that do not allow OpenArgs (e.g. DoCmd.OutputTo). On the other side, this is surely problematic on a shared database, and I suspect it will not work with an MDE ? – Wondrous

Sorry for the downvote, but I thought this was not addressing the problem. – Ripley

Answer 2

This often happens during developpment whem the form is already oppened (in edit mode for example) and you invoke the docmd.OpenForm function. In this case, the form is placed in normal (view) mode and the OnOpen and OnLoad events are raised, but the OpenArgs property is set to null no mater what you passed to docmd.OpenForm.

The solution is obviously to close the form before you invoke it with docmd.OpenForm. However there is a workaround I like to use. In the OnOpen event I check if me.OpenArgs is null and if it is I replace it with some debug values.

if not isnull(me.OpenArgs) then
   myvalue = me.OpenArgs
else
   msgbox "Debug mode"
   myValue = "foo"
endif

Fecundate

That is obviously a bug, since the documentation clearly states that OpenArgs returns a string. I had the same problem today with a report, and it's the first time I see that. Normally I always Len(Me.openArgs) and that always worked fine. – Wondrous

Thanks, my head was really starting to hurt wondering why on earth OpenArgs was always null on my form. The form was open in design mode. Not really the sort of behaviour I would have expected... – Suiting

Answer 3

I just had this problem. The Arg string did not get passed, because the report was already open, but not visible. It had been left open when the code crashed with the Null string error.

The solution was to close the report in the immediate window, with

Docmd.Close acReport, "myReport"

It fixed my bug and the args were passed properly.

Slider

Answer 4

It could be that you had your form open already (as suggested), but just check for null and the form will handle opening with missing arguments as well.

This will allow opening the form for a quick peek (by you or the users) if the arguments aren't vital.

Private Sub Form_Open(Cancel As Integer)
    If Not IsNull(Me.OpenArgs) Then
        Me.lblHeading.Caption = Me.OpenArgs
    End If
End Sub

A null value can be passed to OpenArgs by omitting the value in the OpenForm call, or by double-clicking the form in the Access Objects sidebar.

---

If it's a modal form, you should explicitly check if it's open and close it before opening it if so. This is a common gotcha.

The same could of course be done for all forms, not just modal ones, and then you wouldn't need the null check (provided you never pass null to it). But often there are a lot of forms in a project, and even more OpenForm calls than forms...

Ripley

Answer 5

Is the value taken from a user completed control? Do you ensure that the focus is moved from the control before you run the openform line?

EDIT: The value property of the control will be equal to the previous value, which may be null, unless you do this.

Dumont

Answer 6

I think I found the answer to my problem:

In my experience, OpenArgs has to be handled immediately upon opening of the form. (link)

I checked this by putting a break before attempting to use the OpenArgs value, and it was null. But when I remove the break, the program shows no error. This must only happen while developing.

Azarria

"OpenArgs has to be handled immediately upon opening of the form" I have never found this to be true and I frequently use OpenArgs. – Dumont

The OpenArgs argument is persistent throughout the life of the form instance. – Asinine

Anyway OpenArgs SHOULD be a string, therefore never Null ! I had the same problem today with a report, very strange. – Wondrous

Answer 7

Answer here. your form may be already open, even in Design mode: http://www.tech-archive.net/Archive/Access/microsoft.public.access.formscoding/2007-02/msg00928.html

Euromarket