Fire Department Alert System - Subscript Used With Non-Array Variable Error

[BAVFC3641]

All,

I recently finished a script for my fire department that takes in 911 dispatch data from a website and displays it on an LED marquee in real time, allowing us to see the type and address of an emergency as soon as the 911 dispatcher inputs it in their system (oftentimes up to 30 seconds before the alarm rings and the call gets dispatched).

The script reads the text from the 911 center website every 100ms, checks a buffer to see if the call is new, then uses various string operations to isolate the address and type of call. Consequently, it is ripe for subscript used with non-array variable errors. I accounted for this by always checking using IsArray and zeroing the arrays after every call received.

Here's where things get weird: all the coding was done on a Windows 7 machine (Pentium 4, 2.80GHz; 2GB RAM) and the program left running for weeks on end with no errors. Once I set up the computer at the firehouse, I started getting the subscript error at random times and with no way of reproducing it. As soon as I restart the script, even with the same data, it works flawlessly for another 6-12 hours before crashing. The firehouse machine is running Windows XP SP3 (Pentium 4, 2.80GHz; 512MB RAM) and the script is set up as a 32-bit application on both.

I've run out of ideas as to why this is happening. Is it the RAM on the XP machine? Why does it crash on the XP computer and not on the Windows 7 one? Did I breathe in too much smoke at the last fire and thus am missing something obvious about the arrays?

I'm hoping your combined wisdom can help with pinpointing the issue, for this system needs to be as reliable as all our other emergency equipment. Many thanks in advance!

[hannes08]

Hi BAVFC3641,

if you can provide us your script, we can take a look at it,

troubleshooting this without any scripting will be very hard...

[BAVFC3641]

Find attached. I did not include all the call types to keep the size down, we have over 80 types of alerts. I also left out the GUI code and the functions (FireSend, EMSSend, CombinedSend) since all they do is send the data to the LED board.

Edited August 19, 2011 by BAVFC3641

[hannes08]

First thing I found: If _StringBetween fails, you cannot access $sCalls[0].

[BAVFC3641]

Thanks Hannes123, I'll add error checking to that spot. The issue, however, seems to be focused on the section Checking for pre-alerts. Running the script from the editor shows the error taking place at the Fire Pre-Alert spot.

[hannes08]

Maybe I don't understand your code, but that's the first instance where you try to access $sCalls[0].

I'd also error-check the following line:

$sText = _IEBodyReadText($oIE)

Maybe your XP has some different results here than Win7.

[UEZ]

Maybe you are using different IE versions. Further what is the em exactly? To make a better troubleshooting is it possible to start the script by pressing F5? Because the line number where your script crashes is very important to debug it properly.

Br,

UEZ

Edited August 17, 2011 by UEZ

[BAVFC3641]

Maybe you are using different IE versions. Further what is the em exactly? To make a better troubleshooting is it possible to start the script by pressing F5? Because the line number where your script crashes is very important to debug it properly.

Br,

UEZ

Think it might be IE 8 vs. IE 9? If that's the case I'll need a whole new machine.

As for the error message: "Error: Subscript used with non-Array variable." When running the EXE, it points to line 7857 (no use to me at all). When running within the editor, it points to

; Fire Pre-Alert
Case StringInStr($sCalls[0], "FIRE PRE-ALERT")

[UEZ]

The problem is probably here:

...
        ; Find every call (check between EOC and carriage return)
        $sCalls = _StringBetween($sText, "EOC:", @CR)
...

Add an error check like:

$sCalls = _StringBetween($sText, "EOC:", @CR)
If @error Then DO SOMETHING

Br,

UEZ

[BAVFC3641]

The problem is probably here:

...
        ; Find every call (check between EOC and carriage return)
        $sCalls = _StringBetween($sText, "EOC:", @CR)
...

Add an error check like:

$sCalls = _StringBetween($sText, "EOC:", @CR)
If @error Then DO SOMETHING

Br,

UEZ

Implemented the @error check to see if the error is at that spot. I'll monitor it and post updates as they develop. Thanks!

[BAVFC3641]

Changed the code to check for @error where UEZ mentioned it, then ran the script on both XP and Windows 7. The script on XP threw me an error (where UEZ pointed) around 12 hours later, while the script on Windows 7 is still running at this time with no errors.

I'm legitimately confused now... does anyone else think this is related to the OS?

[hannes08]

First thing I found: If _StringBetween fails, you cannot access $sCalls[0].

Well, I thought I pointed to that also maybe I should have been more clear about which _StringBetween I'm talking...

I don't think this is an OS issue but a IE issue.

Obviously your Script on XP (IE8) doesn't get a proper response or a "valid" page.

You could go and just save the page in case of error so you can see what your script received.

Edited August 18, 2011 by Hannes123

[UEZ]

Probably on WinXP the line $sText = _IEBodyReadText($oIE) will cause the problem because _StringBetween() is failing to find the string and thus no array will be created!

That means that on your WinXP machine _IEBodyReadText() is getting different results than on your Win7 machine because of different IE versions and/or OS versions!

I would suggest to debug $sText to see the difference between WinXP and Win7. If you find out the difference than it is easy to find a solution.

Br,

UEZ

Edited August 18, 2011 by UEZ

[JohnOne]

It would certainly appear its either OS or IE, but probably not an easy to debug one, as its rather weird that it runs for so long before failing.

Heres what I'd do to debug the problem

After the @error check with _stringbetween() function log the contents of $sText to a file and add a continue loop.

That will do two things, first it will show you if your start and end strings are present at the fail, and second it will

Show whether after an initial fail if it will continue to fail or rectify itself.

If it rectifies itself then the continue loop is probably enough to fix the script

because none of the loop script will be ran after it, until a fresh grab of $sText = _IEBodyReadText($oIE)

is performed, which I have a sneaky feeling is where it could be failing (I'm thinking that maybe the page is being updated at the moment the function is retrieving the text)

Why that might happen on one machine and not the next is not something I could try to answer.

But it seems there may be other factors, for a start your at a different location at work,

with a different ISP, and different things happening on the network.

Hope that's of some use to you.

Edited August 18, 2011 by JohnOne

[BAVFC3641]

...

After the @error check with _stringbetween() function log the contents of $sText to a file and add a continue loop.

...

Done. Right now it's running and I'm waiting for any errors, will update as soon as anything happens.

[BAVFC3641]

...

After the @error check with _stringbetween() function log the contents of $sText to a file and add a continue loop.

That will do two things, first it will show you if your start and end strings are present at the fail, and second it will

Show whether after an initial fail if it will continue to fail or rectify itself.

If it rectifies itself then the continue loop is probably enough to fix the script

because none of the loop script will be ran after it, until a fresh grab of $sText = _IEBodyReadText($oIE)

is performed, which I have a sneaky feeling is where it could be failing (I'm thinking that maybe the page is being updated at the moment the function is retrieving the text)

...

Bingo! For some unexplained reason (maybe IE8...?) the dispatch response console goes blank every so often. The ContinueLoop command rectified this problem. I'll implement this change on all machines even though Windows 7 is not giving me any problems. Better safe than sorry.

This script is much more robust and reliable with all the community input. Thank you all for your help!