IsLoaded

[JohnHo]

here is the deal I have a form with a command button to open another form. I would like to check if another form is loaded and use the code to close that form. simple right?

 

Dim obj As AccessObject, dbs As Object 
    
Set dbs = Application.CurrentProject 
Set frm = dbs.Forms!frmCaseInfo 

If frm.IsLoaded = True Then 

 DoCmd.SelectObject acForm, "frmCase", False 
 DoCmd.Close

I've dinked with variations on the above code and get an error "the form is not loaded" or "applicatio n object not defined" or "that method not available".

I cannot determine why. What am I missing?

any help is greatly appreciated & I'm much obliged

/jh

[FishVal]

Hello, JohnHo.

• "Form" class as well as "Form_<formname >" (class of particular form) class has no method/property IsLoaded.
• "Forms" collection contains only opened forms (except those opened within subform controls).

Do you really need to check whether a form is opened just to close it?

Regards,
Fish

[NeoPa]

"Forms" collection contains only opened forms (except those opened within subform controls).

I think you'll find this means that your line #6 will fail if the form isn't already loaded (open).

You can use On Error code to determine whether or not the form is open when you try to access it.

[missinglinq]

This code will do it, replacing FormToBeClosedN ame with your actual form name:

Dim cp As CurrentProject
Dim Frms As Object
  Set cp = CurrentProject()
  Set Frms = cp.AllForms

  For Each Frm In Application.Forms
    If Frms("FormToBeClosedName").IsLoaded Then
      DoCmd.Close acForm, "FormToBeClosedName"
    End If
  Next Frm
  
  Set Frms = Nothing
  Set cp = Nothing

But as FishVal suggested, you don't really need to check to close it. If you try to close a form that isn't loaded, nothing untoward happens.

Linq ;0)>

[ADezii]

Us 'Old Dudes' rely on the traditional approach to checking as to whether or not a given Form is Loaded, and sorry NeoPa, but IMHO, I do not feel as though you should ever rely on an Error being generated to verify that a Form is Loaded/Unloaded, when a viable alternative exists.

Function IsLoaded(ByVal strFormName As String) As Boolean
'Returns True if the specified form is open in Form view or Datasheet view.
    
Const conObjStateClosed = 0
Const conDesignView = 0
    
If SysCmd(acSysCmdGetObjectState, acForm, strFormName) <> conObjStateClosed Then
  If Forms(strFormName).CurrentView <> conDesignView Then
    IsLoaded = True
  End If
End If
End Function

If IsLoaded("<Your Form Name>") Then
  DoCmd.Close acForm, "frmmemo", acSavePrompt
End If

[MikeTheBike]

Hi

In the early days (A97?) this seemed to be the way to check for open forms

Function FormIsLoaded(ByVal strFormName As String) As Boolean
    FormIsLoaded = False
    
    Const conObjStateClosed = 0
    Const conDesignView = 0

    If SysCmd(acSysCmdGetObjectState, acForm, strFormName) <> conObjStateClosed Then
        If Forms(strFormName).CurrentView <> conDesignView Then
            FormIsLoaded = True
        End If
    End If

End Function

(taken directly from am MS publication).

Layer versions of Access permitted/provided this syntax/object

Private Sub Form_AfterUpdate()
    If CurrentProject.AllForms("frmEmployees").IsLoaded Then Form_frmEmployees.LineManagerID.Requery
    If CurrentProject.AllForms("frmNewEmployee").IsLoaded Then Form_frmNewEmployee.LineManagerID.Requery
End Sub

Just though it might help !?


MTB

[NeoPa]

ADezii,

I agree that using On Error is not ideal. For me though, to use SysCmd is even less so. From my point of view that should be reserved for doing something that's logically outside of the application. I'm a strong believer in the logic of code. Being readable as well as working correctly has always seemed an important issue to me. That's not to say that I'm right and you're wrong by any means. Simply that we would disagree on this particular point.

In fact, since MTB has posted, I suspect he's shown some checking code that we would both be happy to recommend.

[ADezii]

ADezii,

I agree that using On Error is not ideal. For me though, to use SysCmd is even less so. From my point of view that should be reserved for doing something that's logically outside of the application. I'm a strong believer in the logic of code. Being readable as well as working correctly has always seemed an important issue to me. That's not to say that I'm right and you're wrong by any means. Simply that we would disagree on this particular point.

In fact, since MTB has posted, I suspect he's shown some checking code that we would both be happy to recommend.

I just figured since Microsoft has use this code syntax in the Northwind Sample Database since the beginning ot time, there must be something to it! (LOL)!

[missinglinq]

Right! They also went from the beginning of time until 2007 with the Command Button Wizard generating the code DoCmd.Close to close a form, even though it will dump a record, without warning, that fails validation before closing the form!

Not a very compelling argument, I'm afraid!

Linq ;0)>

[NeoPa]

I just figured since Microsoft has use this code syntax in the Northwind Sample Database since the beginning ot time, there must be something to it! (LOL)!

I'm afraid it's true that much of the sample code provided by Microsoft, as well as much of the code created by the wizards and macro-recording (Excel, Word etc) is some of the worst I've seen.

I wouldn't say that's true for the code you suggested ADezii. That wouldn't be my choice but it's far from naff. The fact that it's from Microsoft though is not really much of a recommendation I'm afraid.

[ADezii]

Right! They also went from the beginning of time until 2007 with the Command Button Wizard generating the code DoCmd.Close to close a form, even though it will dump a record, without warning, that fails validation before closing the form!

Not a very compelling argument, I'm afraid!

Linq ;0)>

I kinda thought that would be up to the Programmer to make sure that a Form will not close if the data contained within fails Validation, or at the least, give the User a Warning Message indicating failure, then an Option of some sort. I don't think you can blame Microsoft for that, Wizards, of any kind, were never designed to be an end all and should never be.

[missinglinq]

I kinda thought that would be up to the Programmer to make sure that a Form will not close if the data contained within fails Validation, or at the least, give the User a Warning Message indicating failure

That the problem! If the programmer uses standard validation code like this

Private Sub Form_BeforeUpdate(Cancel As Integer)
 If IsNull(Me.NName) Then
   MsgBox "Name Field Cannot be Left Blank!"
   Cancel = True
   NName.SetFocus
  End If
End Sub

and the user leaves the NName field empty, then tries to move to another record or close the form, using the big Access X, the messagebox pops up and when OK is clicked, focus goes to the empty field.

On the other hand, if the user clicks on a custom "Close" button which uses the command DoCmd.Close, the messagebox appears, but on hitting OK the form immediately closes, not giving the user the opportunity to correct his/her error and dumping the record!

Likewise, if the "Required" property on a field has been set to Yes, the field left empty and the custom "Close" button hit, the form will close and dump the record without the usual warning.

In both cases the programmer has attempted to prevent the user from leaving a record incomplete, but using DoCmd.Close to close the form has negated these efforts.

Linq ;0)>

[FishVal]

Wow, Hollywar.

Kind regards,
Fish.

[OldBirdman]

If the form did not have an Access X, and when opened, the Close button were cmdClose.Enable d = False, then

Private Sub txtText1()
    If Nz(txtText1, "") = "" Or Nz(txtText2, "") = "" Then
        cmdClose.Enabled = False
    Else
        cmdClose.Enabled = True
    End If
End Sub

with similar code for txtText2.

This is not meant to cover all cases, as a Cancel button might want to drop any changes and close the form, and Close might be OK if Me.Dirty = False.

[missinglinq]

The simple workaround is, in fact, to use

If Me.Dirty Then Me.Dirty = False
DoCmd.Close

as you suggested, which forces the save, thus triggering any validation/required field warnings. I'm told, in fact, that Microsoft actually added this to the Wizard "Close" code in 2007, thus finally addressing the problem after many years. Of course, this, in turn, introduced another bug! If you use the Wizard to generate a "Close" button on an Unbound form, such as one used as a menu or one used for selecting and printing reports, etc. it'll pop an error! Unbound forms have no Dirty Property!

Linq ;0)>