me.visible = true is false

[John Sh]

I use .visible=true in most load events to control when the form becomes visible.
This works well except for a couple of particular cases.
If I run the software in develop mode or click the accde file all is good.
If I run it from a shortcut with windows minimized then a couple of the procedures run but do not become visible.
The procedure below is one such example.
In this case, because there as a button to click, it seems like the software has stalled.
If I click on the 'Access" icon on the task bar the form is there waiting for input. Clicking a button causes the procedure to run it's course without further ado.
If I do not select this particular procedure, the rest of the system runs without a hitch.

This is a recent development and a scan through the options has revealed no possible causes.

The images show the "Backup" procedure is running whilst not visible, the login screen functioning normally and the form mentioned above after clicking the Access icon.

"Option Compare Database" and "Option Explicit" are mandatory in all of my procedures, I just didn't select them in this case.

Private sArgs As String
Private nCount As Integer

Private Sub btnNo_Click()
    Dim args As String
    Dim nCts As Integer
    nCts = nCount
    args = sArgs
    closer Me
    If args = "species" And nCts = 0 Then
        forReview = False
        DoCmd.OpenForm "Main_Menu"
    Else
        doReview "Species"
    End If
End Sub

Private Sub btnYes_Click()
    closer Me
    If sArgs = "Species" Then
        DoCmd.OpenForm "not_in_list"
    Else
        DoCmd.OpenForm "Reviewing"
    End If
End Sub

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If KeyCode = vbKeyF1 Then
        getHelp Me
        KeyCode = 0
    End If
End Sub

Private Sub Form_Load()
    sArgs = getArgs(Nz(Me.OpenArgs), 1)
    If sArgs = "Species" Then
        nCount = DCount("*", "Not_In_List")
    Else
        nCount = DCount("*", "Herbarium_Collection", "[status] = 'R'")
    End If
    noShowImage
    isOne (nCount)
    If sArgs = "Species" And nCount = 0 Then
        Call btnNo_Click
    ElseIf sArgs = "Species" Then
        Me.btnMsg.Caption = "New species names have been entered" & vbCrLf & "Please verify the spelling before approval."
        Me.btnOpen.Caption = "There " & isAre & " " & nCount & " species name" & No_S & " to be checked." & vbCrLf & _
                             " Will you check " & Is_It & " now?"
        nCount = 0
    Else
        Me.btnMsg.Caption = "Change the 'Status' to 'A' and press 'Enter' " & vbCrLf & "to complete the review of a record."
        Me.btnOpen.Caption = "There " & isAre & " " & nCount & " record" & No_S & " to be reviewed." & vbCrLf & _
                             " Will you review " & Is_It & " now?"
    End If
    Me.Visible = True
End Sub

"

 

[MajP]

This could be a timing issue where events are in conflict. You may want to add DoEvents in you on load event in a few strategic places.

DoEvents function (Visual Basic for Applications)

Office VBA reference topic

learn.microsoft.com

DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent.

DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer or delegating the task to an ActiveX EXE component. In the latter case, the task can continue completely independent of your application, and the operating system takes care of multitasking and time slicing.

Any time you temporarily yield the processor within an event procedure, make sure the procedure is not executed again from a different part of your code before the first call returns; this could cause unpredictable results. In addition, don't use DoEvents if other applications could possibly interact with your procedure in unforeseen ways during the time you have yielded control.

I would put a temporary text box on your form for debugging. And then put a bunch of lines in your code that write to this textbox telling you what has executed. something like. Then you can see where this is hanging. You call a lot of other methods not shown so it cannot be debugged from what you are showing.

Private Sub Form_Load()
    DoEvents
    sArgs = getArgs(Nz(Me.OpenArgs), 1)
    If sArgs = "Species" Then
        nCount = DCount("*", "Not_In_List")
    Else
        nCount = DCount("*", "Herbarium_Collection", "[status] = 'R'")
    End If
    me.txtDebug = " Before No Show Image"
    
    noShowImage
    
    me.txtDebug = me.txtDebug & vbcrlf & " After No Show Image"
    
    isOne (nCount)
    me.txtDebug = me.txtDebug & vbcrlf & " After is one"
 
   If sArgs = "Species" And nCount = 0 Then
        Call btnNo_Click
    ElseIf sArgs = "Species" Then
        Me.btnMsg.Caption = "New species names have been entered" & vbCrLf & "Please verify the spelling before approval."
        Me.btnOpen.Caption = "There " & isAre & " " & nCount & " species name" & No_S & " to be checked." & vbCrLf & _
                             " Will you check " & Is_It & " now?"
        nCount = 0
    Else
        Me.btnMsg.Caption = "Change the 'Status' to 'A' and press 'Enter' " & vbCrLf & "to complete the review of a record."
        Me.btnOpen.Caption = "There " & isAre & " " & nCount & " record" & No_S & " to be reviewed." & vbCrLf & _
                             " Will you review " & Is_It & " now?"
    End If
    
    me.txtDebug = me.txtDebug & vbcrlf & " Before Set visible"
    
    Me.Visible = True
End Sub

 

[John Sh]

This could be a timing issue where events are in conflict. You may want to add DoEvents in you on load event in a few strategic places.

DoEvents function (Visual Basic for Applications)

Office VBA reference topic

learn.microsoft.com

I would put a temporary text box on your form for debugging. And then put a bunch of lines in your code that write to this textbox telling you what has executed. something like. Then you can see where this is hanging. You call a lot of other methods not shown so it cannot be debugged from what you are showing.

Thanks MajP.
The code is not actually hanging. In this particular case it is waiting for input but is not visible.
In the case of the backup procedure, it performs normally and passes control to the next procedure.
I have stepped through the procedure and put msgboxs in here and there.
Apart from the public function "GetArgs" and two public subs "noShowImage" and "isOne (nCount)" there are no other external calls.
All three of the above are used extensively throughout my software.
I have commented the two subs with no effect. I have even compiled on another machine with the same result.
I have included a screenshot of my references, just in case
.

 

[The_Doc_Man]

In this case, because there as a button to click, it seems like the software has stalled.
If I click on the 'Access" icon on the task bar the form is there waiting for input. Clicking a button causes the procedure to run it's course without further ado.

This sounds like a timing issue.

The code is not actually hanging. In this particular case it is waiting for input but is not visible.
In the case of the backup procedure, it performs normally and passes control to the next procedure.

This reinforces that belief.

In your code shown in post # 1 of this thread, you call what appears to be a button-click routine that opens a form. That form will trigger several events such as Form_Open, _Load, and _Current. Does this behavior specifically occur when the sArgs is "species" and the nCount = 0? Because that is the case in the Form_Load that would launch your main menu form. Again, you are calling what appear to be event routines directly as well as allowing them to be evoked by the appropriate Access event. This is a terrible habit to get into and will overly convolute things when you are trying to debug this.

You need to consider what other routines will be running when all of this is going on, particularly if you are going to have multiple forms open at the same time - which in the stated case, you will. Whatever is running that Form_Load routine you showed us, it will be open at the same time that the "Main Menu" form opens. Their events - if properly coded - will not interfere with each other. However, your event threading might become difficult to track. MajP suggested this was a timing error. I agree with him. I also think that a DoEvents might help deconvolute things.

Another thought, though. Remember that MSACCESS.EXE is the main program. The code that you run in event routines always resides in the context of a SUBROUTINE or FUNCTION. It gets called by external callers. At NO TIME can you be assured of what else (what other events) might also be running if you have a multi-form-open case. If you have ANY EXTERNAL PUBLIC VARIABLES that can be touched by both forms, you now have the potential for destructive interference. In more common terms, this is a "too many cooks spoil the broth" case.

THIS is why you never directly call event routines. You call common but external routines and be sure that you know WHEN and WHY you are calling them. Remembering that when you do that, "Me. " doesn't quite mean the same thing in the context of the external code.

 

[John Sh]

In your code shown in post # 1 of this thread, you call what appears to be a button-click routine that opens a form.

The "closer me" is a sub that closes the current form and clears db and fso objects, if any.
The call to "Main_Menu" is an error, corrected, as this procedure should return to the calling routine.

Again, you are calling what appear to be event routines directly

I can't see where this is happening.

.You need to consider what other routines will be running when all of this is going on, particularly if you are going to have multiple forms open at the same time - which in the stated case, you will.

In the case of the supplied code, yes there is the calling form still open but invisible.
In the case of the "Backup" procedure, it is the only form open while it is running

Whatever is running that Form_Load routine you showed us, it will be open at the same time that the "Main Menu" form opens. Their events - if properly coded - will not interfere with each other. However, your event threading might become difficult to track. MajP suggested this was a timing error. I agree with him. I also think that a DoEvents might help deconvolute things.

I tried a few "doevents" and they made no difference.

THIS is why you never directly call event routines. You call common but external routines and be sure that you know WHEN and WHY you are calling them. Remembering that when you do that, "Me. " doesn't quite mean the same thing in the context of the external code.

When I use "Me" as a parameter it is always in the context of "Frm as Form" in the called sub/function. I was using "

dim frm as form
set frm = screen.activeform

But this causes problems when stepping through,.

I have never been trained in any form of software design or engineering, apart from java 001 about 20 years ago. I am completely self taught and started this business at 82. I am now 85.
While I freely admit that my code is not always kosher, I am confused by the fact that these things seem to just happen.
The couple of procedures in question, and their calling procedures haven't been touched in some considerable time.
Even reverting to code that was working and recompiling, I am getting the same problems.
I even compiled on a w11 laptop, I normally use a W10 desktop, and it displayed the same behaviour.
I am going to setup the two problem procedures as stand alone packages and see what happens in that context.

 

[John Sh]

I think I might have bigger problems because Access now is refusing to run. It just comes on for a few seconds and then quits.
John

 

[The_Doc_Man]

If you have the means to do so, FIRST attempt to re-install Access using the "Repair" option. Then, if you have working databases you can safely use for testing of your installation, open and exercise some app or apps. After that, see if your other problems have improved.

 

[isladogs]

I think I might have bigger problems because Access now is refusing to run. It just comes on for a few seconds and then quits.

Before doing anything like an Office repair, check in Task Manager for any leftover instances of Access and terminate them using End Task. Then backup, decompile and recompile your application.

 

[The_Doc_Man]

Before doing anything like an Office repair, check in Task Manager for any leftover instances of Access and terminate them using End Task. Then backup, decompile and recompile your application.

Good point, Colin. In that case, even simpler is to see if you have a .LACCDB file even though you don't think you have Access open. If you do, try to delete it. Then use WTM to remove any "reluctant" instances of Access, then the other actions as suggested. Use the install/repair path AFTER you cannot get relief from these lesser steps.