Error closing form

[hondaman2003]

I have a form in a database that gives the error "The command or action 'Copy' isn't available now" when exiting. Most people that use this form are fine, but some get this error message. It also only happens when exiting this specific form, not other forms. Can anyone help?

 

[TheAceMan1]

How are ya hondaman2003 . . .

What happens if you perform the following:

[blue]If Not IsNull(Me!Note1) Then
   DoCmd.RunCommand acCmdCopy
   [purple][b]DoEvents[/b][/purple]
End If[/blue]

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[hondaman2003]

Over the past week I have been trying everything everyone suggested, but here are the results:

DoEvents had no effect
Using NZ to check for null had no effect
The error number is 2046
The on error event should be the same as got focus shouldn't it?

 

[CaptainD]

I did a little research on that error number.

I found various versions similer to yours. One was fixed by catching the null caused by an emtpy textbox.

Nothing that pointed me to a way to fix yours.

Since we know the error number, and if there is no indication of what ever causes the error causing other problems, you could just clear the error and move on.

Someone chime in if this is a bad idea and why please.

ErrHandler:
    Select Case Err.Number
        Case 2046
            Err.Clear
        Case Else
    
            MsgBox "Error copying to the clipboard. Error # " & Err.Number & ", " & Err.Description, vbYesNo, "Error"
            Err.Clear

    End Select
Exit Sub

 

[hondaman2003]

CaptainD, thank you for doing a little research on this. The key thing to remember is the error happens only when the form is being closed, not during the copy function itself. I have it checking for a null value and if it's null, do not do the copy function.

The other part that gets me in this is I have error handling built in to every event that I use on the form.

The only reason I was able to obtain the error number was some computers give the error and allow you to click past it using a similar approach you just outlined. Other computers act as if the error handling is not being used.

 

[CaptainD]

The only reason I was able to obtain the error number was some computers give the error and allow you to click past it using a similar approach you just outlined. Other computers act as if the error handling is not being used.

Do you have the error trap in the form "Close", "Unload" and "Lost focus" events?

 

[hondaman2003]

Yes

 

[CaptainD]

I found a thread where the person was having the same error when he opend a report and closed it, then went to open the next report.

The fix was setting the calling forms focus.

So as a test, in the unload event of the form that copies to the clipboard. Enter something like.

"Form_YourCallingFormsName.SetFocus"

and see if that works.

 

[hondaman2003]

I will try that, however want you to know that 90% of the time the "problem" form is called from another form. What happens in the rare case that this form was called from the switchboard? Won't it give me an error if the calling form isn't open and i try to set focus to it?

 

[CaptainD]

You can check to see if the form is open before setting the focus

    If CurrentProject.AllForms("YourCallingFormsName").IsLoaded = True Then
        Form_YourCallingFormsName.SetFocus
    End If

 

[hondaman2003]

I have a new piece of information for you. One of the employees just informed me that he stopped closing the "problem" form since it would give the error and simply switch forms. But he was having a problem even closing other forms when the "problem" form was even open. What do you think of that?

 

[CaptainD]

After you mentioned your program not being able to catch the error and the fact that different computers are having similar problems yet behaving different makes me want to start looking at the computers and software updates.

Can you get information on the computers as to type and age, amount of ram, version of Access etc?

See if there is a pattern.

Then I would take a problem computer and make sure it is up to date on service packs for both the OS and MS Office.

Maybe it's not your code.

 

[hondaman2003]

This is where i may be stuck. All the computers are exactly the same since they were order at the same time. In addition the IT department here is so tight on things being secure with this being a heathcare company that they will not do updates willy nilly just because something is out there.

Honestly this is not the only problem that "random" computers have. There are several other problems that one 1 computer have and the next may not.

About the only thing i can have done is a reinstall of access.

I do have another question, many of the computers around here have only the "lite" version of access. Meaning that they are able to open databases using a switchboard or a form that may open on startup that is it. I have found that there are some commands that will not work in that version of access. The interesting part is, some computers that have the "lite" version work and others may not. At this point I do not have a computer that has the full version that has the problem. What do you think about this?

 

[CaptainD]

I feel your pain on the IT issue and deal with many of the same problems.

A Lite version can in dead cause problems but I'm not sure if that is the source.

Did you try the SetFocus? (Including setting it to the switchboard if it was called from there)

 

[CaptainD]

Err... "Indeed"

 

[hondaman2003]

Working with it now

In dead works fine for me..HA HA

 

[captphan]

HondaMan this seems quite a perplexing problem.
I think you need to beef up your error handling significatly to get some answers.

Try something like this

PROCEDURE_NAME}_Err:
	Select Case Err.Number
		Case 2046
			
			DoCmd.SetWarnings False
			DoCmd.RunSQL "INSERT INTO ErrorLog ( ErrNumber, ErrDescription, ErrFunction, ErrDateTime, ErrLine, ErrModule )SELECT " & Err.Number & "," & chr(34) & Err.Description & chr(34) & " , '{PROCEDURE_NAME}', # " & Now() & "#, " & Erl() & " , '{MODULE_NAME}';"
			DoCmd.SetWarnings True
			Resume {PROCEDURE_NAME}_Exit

	End Select

The lack of a Message box will mean your users are not interupted. I log by placing the information in a table, but you can place it anywhere.

The Erl() comes from adding line numbers, this step may not be nessasry but if it is look at MZTools. In any case you at least need the procedure.

I think the important thing is that you DON'T msg the user. From what you have said the process works so the only true error is the msg.

Some questions you may want to answer for people better at this than me.

What version of Access?

How many simultaneus users?

Do they have individual front ends or are they all sharing one DB?

 

[CaptainD]

You could also add the computer name to the list to see what computers have the problem.

There are various ways, Environ might be the easiest but there are some here that do not like using "Environ".

CompName = Environ("computername")