RegEx does not preview like it validates?

My goal is to return a string in all uppercase.

If I just use the ToUpper() method, HTML entities (i.e. & ) are also capitalized which causes them not to render correctly (I assume they are case sensitive). So I came up with this:

var result = "b&m baKeD Beans";
// convert string to uppercase while leaving all tags and HTML entities lowercase
result = result.replace(/[a-z]+(?!([^<]+)?>)(?!([^\&]+)?;)/gi, function(match){ return match.toUpperCase() });
return result;

When I validate, the string correctly converts all non-entity, non-tag alphas to uppercase, but when I preview/compose, the result is missing the ampersand (yes, I have "treat as tagged text" checked).

If I comment out the line with the regular expression, the value returns with the ampersand (but obviously not in all uppercase). What is the cause of this, and is there another way that I can achieve my goal?

While I'm still baffled as to why the original method does not work, I was able to change my logic around to produce a working result:

var result = "b&m baKeD Beans";
// convert everything to uppercase, and then change entities back to lowercase
result = ToUpper(result).replace(/\&(.*?;)/gi, function(match){ return ToLower(match) })
return result;

The regex no longer captures HTML tags since I need them to remain TitleCase (i.e. font names can not be all lower/upper. Instead, I perform the replace on the value before I add the tags.

If anyone (i.e. Dan) cares to troubleshoot the original regex, I'd still be interested in knowing why it doesn't work in the preview despite working in the validation.

If you uncheck the "Treat returned strings as tagged text" box with the first version of the rule, you can see in the output that the regular expression isn't working as expected at composition time, returning, "B&AMp;M BAKED BEANS". You could also call the Print function in the rule to write the composition-time result to the log (.msg) file.

Basically, the problem is that the JavaScript engine in your version of FusionPro, at least in the composition engine in the FusionPro application, doesn't support the "?!" notation to denote a "lookahead" pattern. However, the Acrobat plug-in on Mac, where the validation in the rule editor occurs, actually uses a newer version of JavaScript which does support that notation, so the regular expression works correctly there.

As noted in this thread, the upcoming FusionPro 8 will use the same newer version of JavaScript for both composition and rule validation, on both Windows and Mac. This should eliminate any cases of rules working differently at validation and composition time (although this is only among a very small handful of cases of that which I've seen in the field). I have verified that your original regular expression works correctly in FusionPro 8, in all contexts.

So, if you want to wait a bit for FusionPro 8, that will resolve the issue with the original rule. Meanwhile, it seems that you have already discovered a workaround.

All that said, though, I would approach the problem in an entirely different way. Instead of trying to take a string which has already been escaped with entities, I would start out with the original data, with the ampersand in it ("b&m baKeD Beans"), then apply the ToUpperCase function to that, and then, finally, use the TaggedTextFromRaw function to escape characters in the uppercase string for tagged markup as necessary.

Better yet, I would just take the original data, convert it to uppercase, and leave the "Treat returned strings as tagged text" box unchecked. Then you can just return the string without having to worry about entities at all.

Basically, the problem is that the JavaScript engine in your version of FusionPro, at least in the composition engine in the FusionPro application, doesn't support the "?!" notation to denote a "lookahead" pattern. However, the Acrobat plug-in on Mac, where the validation in the rule editor occurs, actually uses a newer version of JavaScript which does support that notation, so the regular expression works correctly there.

Thanks for the follow-up Dan. My colleagues and I thought this issue with the two engines might be the case after reading an earlier post about it.

All that said, though, I would approach the problem in an entirely different way. Instead of trying to take a string which has already been escaped with entities, I would start out with the original data, with the ampersand in it ("b&m baKeD Beans"), then apply the ToUpperCase function to that, and then, finally, use the TaggedTextFromRaw function to escape characters in the uppercase string for tagged markup as necessary.

I will see if this works with the strings I receive from a custom portal. I had forgotten about the TaggedTextFromRaw function.

Better yet, I would just take the original data, convert it to uppercase, and leave the "Treat returned strings as tagged text" box unchecked. Then you can just return the string without having to worry about entities at all.

Easy would be best, but the string I receive is more complicated than my OP's example. For the post, I was trying to simplify as much as possible, but in reality, I am receiving data from a web portal which already includes tags and entities.