I found an amusing little behavior in the API. In fact I can't actually write this up perfectly, because all the & #124; codes in my examples keep getting interpreted. Suffice it to say that the first code example should be showing & #125 (without the extra space) as a code, not the pipe character; I am writing code that is writing a drop down query macro, and changing the macro button as conditions change. I want this macro to have submenu's, so of course it has to replace all the closing brackets, pipes and commas with the appropriate code, like this. (without spaces between the & and the #). var sm = ":" + submenu.replace( /\}/g, "& #124").replace( /\|/g, "& #125").replace( /\,/g, "& #44");
Now the funny thing is that it all worked and was tested and all OK yesterday, but today it was not working. Then I noticed that in my code, } and the other two codesvhad been interpreted so the line looked like var sm = ":" + submenu.replace( /\}/g, "}").replace( /\|/g, "|").replace( /\,/g, ","); IE: it now says replace all the pipes with pipes, not replace all the pipes with the code for pipes. So I put it back how it needed to be, and it was fine until I saved it and then exited and reentered the scripts environment, by which time they had been interpreted again! So the work around was to break the code up into two pieces. var sm = ":" + submenu.replace( /\}/g, "&"+"#125;").replace( /\|/g, "&"+"#124;").replace( /\,/g, "&"+"#44;"); Like I said, this might not be a bug per see, but it is something to watch out for, and if you need the actual codes in your code, break them up into two parts.
