5 posts in this topic
Hello, I recently opened a bug report without reading the Helpfile... My bad . After @Melba23's gentle reminder, I was curious about why it was like that.
It is about SetError's behaviour. This is the example from the bug report:
Example() If @error Then ConsoleWrite("Error" & @CRLF) Else ConsoleWrite("No Error" & @CRLF) EndIf Func Example() SetError(1) Sleep(1000) EndFunc What I tried to do is set Example's (my user defined function's) @error value to 1... but the value set by SetError is cleared after calling a function, I wonder why? Why should calling to an external function effect my function's @error which is set when my function returns.
Setting the error of a UDF in advance by using SetError makes sense... but I cannot find a reason why calling a function should clear it? Please note that I am not talking about @error, I am talking about the @error set by my function when it ends/returns!
I hope someone can enlighten me, thanks for the answers in advance!
P.S I tried to explain my best but my English is not very good and I didn't feel like I did a good job explaining today, so please pardon any mistakes that I have made
UDF to intercept the error window of AutoIt, showing more details about the error, including ability to save and send by email!
I get this error, Whenever I try to find a date. Does anyone have any idea why? I saw some post from 2015, However I would imagine this is fixed by now. @water
>"J:\Temporary Files\XXXXXXXXX\AutoIt\AutoIt\AutoIt\SciTe\..\autoit3.exe" /ErrorStdOut "C:\Users\XXXXXX\Desktop\Call Report Automation.au3" "J:\Temporary Files\XXXXXXXX\AutoIt\AutoIt\AutoIt\Include\Excel.au3" (656) : ==> The requested action with this object has failed.: $aResult[$iIndex] = $oMatch.Name.Name $aResult[$iIndex] = $oMatch^ ERROR >Exit code: 1 Time: 5.791 #include <Excel.au3> Global $sExcelFile1 = FileOpenDialog("Choose/Create Excel File", @ScriptDir, "(*.xlsm)") Global $sExcelFile2 = FileOpenDialog("Choose/Create Excel File", @ScriptDir, "Excel Sheet (*.xlsx;*.xls)|All (*.*)") If FileExists($sExcelFile2) Then Global $oExcel2 = _Excel_Open () $oExcel2 = _Excel_BookOpen($oExcel2,$sExcelFile2) EndIF If FileExists($sExcelFile1) Then Global $oExcel1 = _Excel_Open () $oExcel1 = _Excel_BookOpen($oExcel1,$sExcelFile1,Default,Default,"2007") EndIF $oRead = _Excel_RangeRead ($oExcel2,Default,"A2",3) _Excel_RangeWrite ($oExcel1,"Calls Handled",$oRead,"BY7") Sleep (1000) _Excel_RangeFind ($oExcel1,$oRead,"E4:FD92") MsgBox (0,"Test",$oRead) UPDATE:
If I take out this line it works. By works I mean I don't get the error. :/ However, I need it. I am just confused.
_Excel_RangeWrite ($oExcel1,"Calls Handled",$oRead,"BY7")
UPDATE 2: I also get this error when trying to use the helpfile examples. I have version 184.108.40.206
\AutoIt\AutoIt\AutoIt\Include\Excel.au3" (670) : ==> The requested action with this object has failed.: $oSheet = $oWorkbook.Sheets($iIndexSheets) $oSheet = $oWorkbook^ ERROR >Exit code: 1 Time: 0.8931
I am looking for a way to retrieve filtered messages from the ‘system debug channel.' also known as ‘kernel-mode debug output.'
AutoIt must do the capture in real time. The following AutoIt UDF almost does what is required but it only captures application level, or Win32 debug output.
The utility DebugView by Sysinternals captures the information as required by turning on Capture Kernal and in my case using the Filter include:
The use of DebugView to do this is covered in the following tech note;
However to make to make the information from DebugView available to my AutoIt script required DebugView capture to a text file and then my AutoIt script monitor that file for changes. The use of DebugView to capture the system debug channel could be made to work, but it was less than reliable and difficult to get started. The startup wasn’t something that could be easily automated not even with AutoIt.
If you understood what I am talking about and made it this far, I think an explanation of the application is in order. Lots of details here sorry trying to answer questions in advance.
I support a large installation of General Electric MUSE application. MUSE is a Windows-based medical application that processes and archives ECGs (electrocardiograms) taken on dedicated hardware (ECG Carts). Several methods exist on the cart to get the ECG from the Carts to the MUSE system; they range from floppies (on old obsolete hardware), memory cards, RS232 serial ports, and hardwired network connections.
In our installation, we choose not to use the vendor-supplied network solution due to a variety of reasons I won’t get into here. Instead, we have designed our own connection solution.
We use a wireless serial server mounted on the ECG carts connecting to a server running a Serial/IP COM Port Redirector. The ECG cart and MUSE application think they are talking to each other via an RS232 port and as far as they are concerned, they are. However, this RS232 cable happens to run through our province (think State) wide Health Care WAN. The hardware and software used can be seen on these two sites;
This setup works well we have over 130 ECG carts connecting using this setup. However, the end users are not technical, and there is a lot that can go wrong with wireless connections. So we do get complaints, often after the fact, that the ECG cart would not connect. A log of what ECG carts connected and when would be very helpful.
The Serial redirector software can be configured to log all activity to the Kernal-mode Debug output. The serial redirector software itself being kernel level software. For configuration of the Wireless modules, we have custom written software (written in AutoIt) that amongst other things can display relevant configuration information for a Wireless module given it’s IP address.
By extracting messages like the ones below from the Kernal-Mode Debug channel;
COM56 : ½ Incoming connection from 10.158.188.172:51562
COM18 : ½ Incoming connection from 10.158.188.200:50896
COM19 : ½ Incoming connection from 10.158.188.180:59074
COM68 : ½ Incoming connection from 220.127.116.11:34322
We can have the module configuration program retrieve the configuration. The retrieved configuration contains more information such as the module ID number and wireless signal strength. This information is then logged to a file which is later loaded into a database. We can then query the database for connections made by a particular module within a specified time frame. The results of these Queries help us determine if the module was connected or is having problems connecting. Problems are usually indicated by poor signal strength and frequent re-connecting.
So what I am looking for is a way for our module configuration program (written in AutoIt) to retrieve filtered Kernal-Level debug messages directly without using the DebugView application.
The Forum post listed at the first of this message includes the source code for the DLL. So if you are versed in these matters and Visual Studio this may be an easy task. I looked at what needed to be done but, I was way over my head. If you look up the price of the serial IP redirector software, you can see that there is some money in our project for such things however, I do have a spending limit for purchases such as this.
Is there any UDF for Zeromq ?
I need to communicate with a remote and local socket. Any suggestion or guidance will be very appreciated.