Problem with ExcelCom_UDF

[ray306]

It would appear that there is a problem with the function _ExcelSheetUsedRangeGet in the ExcelCom_UDF.

The problem would appear to be the invoking of :

$aSendBack[3] = Number(StringRegExpReplace($aSendBack[0], "\a", ""))

this call is on line 2110 in the ExcelCom_UDF I have. This call is supposed to strip away the non numeric part of an Excel cell address. (ie. A51 becomes 51). It would appear that the syntax for StringRegExpReplace() may have changed in the newest version as I did not have a problem with this until I updated last evening.

The code should be:

$aSendBack[3] = Number(StringRegExpReplace($aSendBack[0], "[A-Z,a-z]", ""))

I tested the suggested replacement code and it appears to work properly.

BTW thanks to all the people that put ExcelCom_UDF together as well as all the Autoit developers, it has been very helpful.

Ray

[Jos]

Please post these issues in the General Help forum since this is not a part of the standard distribution..

- moved -

[Locodarwin]

Thanks for the report, Ray.

StringRegExpReplace() has changed at least once in the last couple of months to the point where it breaks some of the functions in my collection. I haven't mentioned it before because I understood the regular expression functions were in flux. Perhaps it's time to pop the question.

This may be a bug; If someone could tell me why the following code would/should not strip away non-numeric characters from the string, I would appreciate it:

$sTemp = StringRegExpReplace("ABC123", "\a", "")

It used to work, and now on some recent builds it doesn't. It should work, shouldn't it? What's the status of the regular expression functions? I haven't been able to test this against every build myself, but I have been receiving regular complaints about it no longer working.

-S

[randallc]

Hi, not sure except it has changed; see help file?

\a Alarm, that is, the BEL character (chr(7)).

[:alpha:] letters

Best, randall Edited January 15, 2007 by randallc

[Locodarwin]

Ah. Yep. That would constitute a code-breaking change. Thanks, Randall.

Ray, I'll have a full ExcelCOM_UDF update which addresses this change within a day or two.

-S