Resume Next is not working in this case ...

[Bruin1953]

VB6 Code, under Win XP

Private Sub Timer1_Timer()
Dim sTxt As String, L As Long
On Error Resume Next
L = 0
L = Len(Clipboard.GetText)
If L > 1000 Then Call ProcessClipboard
End Sub

Because the timer's interval is one second, a conflict is almost certain. The Clipboard will now and then be busy with another app (copying, pasting, etc).
Unfortunately, "On Error Resume Next" does not work in this case, and THIS app will crash (in my case at least!).
To see what I mean, run and try to paste something repeatedly and rapidly in another app.
Any idea why this error escapes trapping?

[techgnome]

1) there's no need for "Call" ... it's implied
2) None of us can run that code unless you tell us what ProcessClipboard looks like. For all I know it does this: 1/0
3) There are some errors for which no amount of Resume Next will work... maybe if we knew the nature of the error you're getting, we might be able to help
4) OERN isn't error handline=g... it's error ignoring... rather than ignoring any errors maybe you should be working to mitigate or handle any errors that could come up


-tg

[Bonnie West]

Unfortunately, "On Error Resume Next" does not work in this case, and THIS app will crash (in my case at least!).
...
Any idea why this error escapes trapping?

You've now discovered that VB's error trapping mechanism is ineffective against errors thrown by the OS (and also by Win32 APIs). Therefore, you should now use VB's error trapping statements judiciously; do not just sprinkle them everywhere. In particular, placing an OERN at the start of every procedure is very bad. You won't receive any useful error alerts (especially while debugging) because you chose to ignore all of them.

Having said that, how far is your code in Sub Timer1_Timer() able to go before it crashes? In order to determine that, you'll have to delete the OERN line and then log your code's activities to a file.

BTW, always keep the following reminder from MSDN in mind:

The clipboard is user-driven. A window should transfer data to or from the clipboard only in response to a command from the user. A window must not use the clipboard to transfer data without the user's knowledge.

[Bruin1953]

1) there's no need for "Call" ... it's implied
2) None of us can run that code unless you tell us what ProcessClipboard looks like. For all I know it does this: 1/0
3) There are some errors for which no amount of Resume Next will work... maybe if we knew the nature of the error you're getting, we might be able to help
4) OERN isn't error handline=g... it's error ignoring... rather than ignoring any errors maybe you should be working to mitigate or handle any errors that could come up
-tg

Thanks
The problem is NOT with ProcessClipboard
It occurs occasionally at: L = Len(Clipboard.GetText)
Obviously — I think! — the other app is engaging the clipboard at that exact moment.
Pls not that I leave this app specifically to copy something

[Bruin1953]

You've now discovered that VB's error trapping mechanism is ineffective against errors thrown by the OS (and also by Win32 APIs). Therefore, you should now use VB's error trapping statements judiciously; do not just sprinkle them everywhere. In particular, placing an OERN at the start of every procedure is very bad. You won't receive any useful error alerts (especially while debugging) because you chose to ignore all of them.
Having said that, how far is your code in Sub Timer1_Timer() able to go before it crashes? In order to determine that, you'll have to delete the OERN line and then log your code's activities to a file.
BTW, always keep the following reminder from MSDN in mind:

Thank you for the good inside, ie, OS errors vs VB errors.
As I stated earlier, the error is raised because the clipboard is busy with the other guy.
A solution may be to inspect the clipboard after returning from the other app.
I will keep you posted.

[Bonnie West]

Can you tell us what your app is doing with the Clipboard? The code you've shown seems to be monitoring it using a Timer, BUT that isn't the way the Clipboard is supposed to be monitored. It looks like your issue stems from incorrect usage of the Clipboard.

[techgnome]

Thanks
The problem is NOT with ProcessClipboard
It occurs occasionally at: L = Len(Clipboard.GetText)

Well that would have been good information to know, don't you think?

Obviously — I think! — the other app is engaging the clipboard at that exact moment.
Pls not that I leave this app specifically to copy something

What is obvious to isn't to the rest of us. Especially when something is being done that seems a bit iffy.

Thank you for the good inside, ie, OS errors vs VB errors.
As I stated earlier, the error is raised because the clipboard is busy with the other guy.
A solution may be to inspect the clipboard after returning from the other app.
I will keep you posted.

That may or may not be the solution... it depends on what the error is.

-tg

[incidentals]

have you simply put a debug.print or stop in the code so that you can look at the errno and see exactly what the error code is...

you can then refine your actions in light of this information

rather than best guessing, which is what you are doing now.

here to help

[Bruin1953]

The message I get:
521 Can't open Clipboard

To see for yourself, have a program with Timer1, interval=500 (mine = 1000)

Private Sub Timer1_Timer()
Dim L As Long
L = Len(Clipboard.GetText)
End Sub

After running the program, go to Notepad, copy a few lines and paste them repeatedly and quickly; you will get the error when both apps try to access the clipboard simultaneously.

The topic is "solved' here:
http://www.vbforums.com/showthread.p...lipboard-error!
I will try it.

MS says "trap the error", but neglects to show how!
http://msdn.microsoft.com/en-us/libr...=vs.60%29.aspx

[techgnome]

You trap the error by using On Error GoTo ... checkign for Error # 521 and dealing with it.


-tg

[Bruin1953]

You trap the error by using On Error GoTo ... checkign for Error # 521 and dealing with it.
-tg

Please note that I titled this thread "[ON ERROR] Resume Next is not working in this case ...".
I can't see how THIS error can be trapped.
BTW, I just exit the error box and hit F5 to resume execution (because the Clipboard has been released by the other app).
That is OK in IDE, but not in the Exe version of the program.

[techgnome]

I didn't say use OERN did I? I went back and re-read what I wrote, and sure enough, I didn't say anything about OERN.
You asked how to trap the error... that's using On Error GoTo ... NOT On Error Resume Next which ignores errors, and doesn't handle them or trap them... there is a clear difference between how OERN and OEGT work.

Something else that I just remembered... does this error ACTUALLY happen in the compiled version? Or is the ASSUMPTION that it will because it is happening in the IDE? I ask because there is a setting in the IDE that allows you to control how the IDE breaks for debugging when dealing with exceptions. It might be that you have Break on all errors, which I normally prefer, but in this case it may be giving a false sense of "OERN" not working. I don't have VB6 so I don't remember exactly where it is, but it's under a toggle menu item somewhere. I want to say that if you right-click in a code window, I think there is a toggle option... which expands out one or two more levels... you're looking for "Break on all errors" and "Break only on unhandled errors" ... it's that last one you really want.

But if this IS in fact happening in compiled code and not just in the IDE... beats me. I don't like OERN, so I don't use it, so I couldn't tell you.


-tg

[Bonnie West]

Can you tell us what your app is doing with the Clipboard? The code you've shown seems to be monitoring it using a Timer, BUT that isn't the way the Clipboard is supposed to be monitored. It looks like your issue stems from incorrect usage of the Clipboard.

You are getting Clipboard errors because you are not doing it the right way. You are polling the Clipboard instead of just receiving notifications from it. "Polling is bad". If you want to receive notifications from the Clipboard when its contents changes, you'll have to employ subclassing. The modHookClpBd.bas module here takes care of all the low-level details for you; you just need to insert the relevant procedure from your code in two separate places in that module and then call the HookClipboard function to start monitoring the Clipboard.

[Bruin1953]

I didn't say use OERN did I? I went back and re-read what I wrote, and sure enough, I didn't say anything about OERN.
You asked how to trap the error... that's using On Error GoTo ... NOT On Error Resume Next which ignores errors, and doesn't handle them or trap them... there is a clear difference between how OERN and OEGT work.
Something else that I just remembered... does this error ACTUALLY happen in the compiled version? Or is the ASSUMPTION that it will because it is happening in the IDE? I ask because there is a setting in the IDE that allows you to control how the IDE breaks for debugging when dealing with exceptions. It might be that you have Break on all errors, which I normally prefer, but in this case it may be giving a false sense of "OERN" not working. I don't have VB6 so I don't remember exactly where it is, but it's under a toggle menu item somewhere. I want to say that if you right-click in a code window, I think there is a toggle option... which expands out one or two more levels... you're looking for "Break on all errors" and "Break only on unhandled errors" ... it's that last one you really want.
But if this IS in fact happening in compiled code and not just in the IDE... beats me. I don't like OERN, so I don't use it, so I couldn't tell you.
-tg

Thanks, I know you are trying to help.
And you have been of a great help indeed.
I changed Options>General> to "Break on unhandled errors", OEGT is now working in IDE. I am not sure about compiled.

However, it is now clear that universal "Clipboard.GetText" is a bad idea to begin with. It is much easier to inspect the clipboard only when the inspecting applications regains focus.
Thanks again.