trap system tray error message (e.g. "No Disk" exception)

[orbs]

hello all,

I'm having a script running FileCopy function, where the target happend to be an unstable hard drive.

I can replace my hard drive (and I will soon), but this is not my concern.

when FileCopy fails, I can read the return code and work with it, and that's fine; but Windows tends to get in the way with a baloon tip saying: "AutoIt v3: Windows - No Disk". my concern is what happens when this script runs on some other computer in my enterprize and encounters the same issue. I want to trap the error before Windows starts alarming the end-user with spooky messages.

see attached file for screenshot of the error message.

I considered that the script will check drive status before filecopy, but this does not handle instability of hardware, just the media being ready / not ready.

any suggestinos are welcome (also, is there a way to display a screenshot in the thread text?)

thanks,

Or

[guinness]

Probably best to get a new hard drive in all honesty.

[orbs]

hello guiness, I must have failed to explain my purpose: I don't care for my disk, I will replace it, but I don't want my script to issue these messages on other machines which may have the same or similar hardware failure. so I want to trap these system messages before they appear and make my users call me with panic. I suspect this example is not the only system message regarding hardware failure which may occur, so I want to trap them all and process them inside the script.

[BrewManNH]

Why wouldn't you want to let the user's know that your script has a problem because their drives are failing? It's called good customer service.

[orbs]

hi BrewMan, consider this: if you were a not-too-computer-oriented user, how would you respond to this message suddenly popping up your screen?

I'd be happy to replace this message with a standard MsgBox saying something like "a hardware failure has occurred please contact your system administrator."

also, as I mentioned, I suspect this is only one example of a wide range of system failures that I would be happy if my script could detect and handle internally.

[guinness]

However you present the message to the end user, they will always be like "what is happening!?"

Edit: Post a small reproducer too.

Edited January 13, 2013 by guinness

[trancexx]

Good practice is that your application controls displaying error messages. System does it and will do it only if you fail to handle critical type of errors.

This is done by calling SetErrorMode function as one of the first things you do in the script if there is even a remote possibility critical error will occur. See this example:

Global Const $SEM_FAILCRITICALERRORS = 1

; This is the line. You are telling: I'll handle possible displaying of critical errors myself
SetErrorMode($SEM_FAILCRITICALERRORS)

ConsoleWrite(FileOpen("A:") & @CRLF) ; This line would create system's critical-error-handler message box for my system if I haven't called SetErrorMode passing SEM_FAILCRITICALERRORS argument


Func SetErrorMode($iMode)
    Local $aCall = DllCall("kernel32.dll", "dword", "SetErrorMode", "dword", $iMode)
    If @error Then Return SetError(1, 0, 0)
    Return $aCall[0]
EndFunc

Edited January 13, 2013 by trancexx

[kylomas]

trancexx,

When I run this with "seterrormode" commented out I do not get a windows error, just a -1 return from fileopen.

Script run in 32 bit mode on Win7 (64 bit) OS at current maint levels.

kylomas

[trancexx]

trancexx,

When I run this with "seterrormode" commented out I do not get a windows error, just a -1 return from fileopen.

Script run in 32 bit mode on Win7 (64 bit) OS at current maint levels.

kylomas

Why do I need to know that? I said what will happen for me, not you.

[orbs]

thanks trancexx, this seems to be exactly what I was looking for! and thanks for the reference!

I added your code to my script, unfortunately I wasn't able to test it yet, because I first tried to reproduce the error with my original script - but my unstable hard drive has been behaving well all day! how frustrating, you just can't trust an untrusty hardware these days...

I will continue with my effort, and (hopefully) post some conclusions shortly.

many thanks again,

Or