ZiggyStardust

Well Melba23 guess what? You are a horses ass! I have seen your other posts to those who have violated forum rules and all I can say is that you need to find a different job because you aren't very good at the one you have. You don't have a life so you have to play God on the forum just to give your life some kind of meaning? What flexibility? Why bother? I have better things to do then deal with the likes of you! Get a life!

They are two distinctly seperate questions. The one you referred to above was how do you recover from a CommMG error. This one is "I need another serial UDF" I keep getting chastised for this. You really consider these two to be the same question?????

I started out using the CommMG UDF but have found it to be maybe not so good. I am doing serial I/O via a USB to Serial Converter (virtual ComPort) and it does the I/O really well but I find it to be fatally flawed when it comes to error handling. I hope I am wrong but here goes. I have written a very simple script: #include <CommMG.au3> Global $Port=35, $Baud=115200, $Databits=8, $Parity="none", $Stopbits=1, $Flow=2, $RTS=3, $DTR=2 Global $Received, $Result, $PortList[100] Global $oMyError = ObjEvent("AutoIt.Error", "MyErrorFunc") $PortList = _CommListPorts(0) $Result = _CommSetport($Port, $Received, $Baud, $Databits, $Parity, $Stopbits, $Flow, $RTS, $DTR) $Result = _CommSetTimeouts(5,5,5,5,5) _CommSendString("010D" & @CR, 0) $Received = _CommGetLine(">", 100, 2000); Should get back speed Exit Func MyErrorFunc() Beep() Beep() Exit EndFunc The problem happens when the user pulls the USB cable out of the computer (or if you run this the port does not exist). 1) It seems to resist the COM Error Handler (I guess no biggie) but 2) it appears as though the commmg.dll has its own error handling and pops up with a error message and asks the user to click on OK. That is a show stopper of me. What is the point in checking @error and return codes when the UDF does its own thing anyway? I don't want the UDF to display an error and ask the user for input. I want to handle the error. Anyway.... if someone sees a way around it and I could still use CommMG I really like it but I have a feeling I need another serial comminication UDF. Can anyone recommend one that does not have the above flaws? Thanks!

Thanks Water. Per your suggestion I installed Beta 3.9.4.0 and there was even a COM Error Handler test. The test ran and caught the COM Error. I put the Error Handler in my script and it blew right past it and crashed. I am out of things to try. I left a post on the CommMG UDF thread. Maybe a suggestion will turn up. Your suggestions and input were greatly appreciated!

3.3.8.1? How do you tell for sure? I am a little fuzzy about what is classified as a "COM" error. I tried putting in a COM Error Handler yesterday and unplugging the USB cable. It blew right past the COM Error Handler and crashed. You really think the beta would catch this unhandled exception error and let me recover from it? Google has failed me! What is the definition of a "COM Error". I am especially curious as to what the COM stands for. All I can find is that it is a generic term for a Windows crash.....

Just thinking out loud. Since this exception can't be handled would anyone see a problem with running yet a second script which would do nothing more than make sure the first script was running. If the second script crashed with the exception the first script would simply re-run the second script. I know from experience that, as a rule, when you get one of these exception errors you might as well reboot because nothing is going to work right. Any other input on how I can handle this?

I have been pulling my hair out on this one. I have a well working script that does extensive comm I/O to a virtual ComPort (USB to Serial Converter). Love this UDF and can't say enough good things about it. The problem is that if I pull the USB cable out of the computer while the script is running AutoIT crashes with the unhandled exception error "autoit.exe has encountered a problem and needs to close" at which point the script terminates. The were early references to that problem in this thread but no real soultion. It has been a while. Has anyone found a soultion?

Here is the lowest level I/O I do: Func CommSend($SendStr) $Received = "" _CommSendString($SendStr & @CR, 0) If @error <> 0 Then $CommError = True WriteLog("Error sending " & $Sendstr) Return EndIf $Received = _CommGetLine(">", 100, 2000); Should get back speed If @error <> 0 Then $CommError = True WriteLog("Error receiving " & $Received) Return EndIf $Received = StringStripWS($Received, 8) ; Strip Carriage Returns EndFunc

The only thing I get from SciTE is Exit Code: 250477278 I use CommMG.au3 and simple to reads and writes to COM16. The script works really well and I can't feel too sorry for the user is they pull the USB cable out of the computer in the middle of the script but need to try and overcome this one last issue. Even rebooting the computer would be an acceptable solution. I just can't find a way to intercept this "Windows Crash".....

I tend to agree There is no way to intercept this kind of error?

I can tell you what triggers it. I do I/O to a virtual COMPort (USB). If I pull the USB cable out of the computer while the script is running it generates the Windows crash. "autoit.exe has encountered a problem and needs to close. We are sorry about the inconvenience". Since this is a Windows Error is there any way I can control it?

I have a script that will (by way of user interaction) generate the Windows standard "autoit has encountered a error and needs to close... send, don't send" and the program terminates. Is there any way around this (other then shooting the user)? Utlimately what I would like to do is re-run the program if it crashes or better still keep this from happening. Thanks!

Thanks BrewManNH. I played around with it and it was not possible to check before each I/O. It is doing nothing but streaming I/O and no matter how many checks I do odds are about 50/50 that the user will pull the cable between a check and an I/O.

I have written a program that does extensive I/O to a virtual USB ComPort. The problem is that if the user pulls out the USB cable the virtual ComPort disappears and program crashes with the Windows standard "autoit has encountered a error and needs to close... send, don't send" and the program terminates. Is there any way around this (other then shooting the user)? Utlimately what I would like to do is re-run the program if it crashes or better still keep this from happening. Thanks!

Shoot. I just asked this in another thread. I am trying to find an answer too. I have looked at WinSetOnTop but it doesn't guarentee your Windows will always be on top. I am looking for a way to determine which Window is "On Top" so I can close them until my windows is on top. Any ideas?