[SOLVED] "Attaching the Script debugger to process iexplore.exe failed" message after upgrading to Internet Explorer 10

HUGE thanks going out to Dmitri Leonov - MSFT in a stackoverflow article about the same message.
After updating to Internet Explorer 10, I started receiving the error when debugging with Visual Studio 2010:

"Attaching the Script debugger to process [####] iexplore.exe failed.  Another debugger may already be attached to the process."

The fix:

• Close all instances of Internet Explorer.  (I will add you can leave Visual Studio open)
• Run a command prompt as Administrator and paste this little gem into the command line:

  regsvr32.exe "%ProgramFiles(x86)%\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll"
It worked like a champ for me (and apparently others from comments on the stackoverflow post.)

Good riddance to an annoying message!  Happy coding.

Compatibility Tag for Internet Explorer 8

Microsoft emailed me today to warn me that Internet Explorer (IE) 8 will now be in "Standards Mode" by default instead of the "Compatibility" (sometimes referred to as "Quirks") mode the older versions have run in.

This means that web developers that may have sites out there with invalid markup may run into some issues for people viewing their sites using IE 8.

This is a GOOD thing Microsoft is doing, as it will make their browser play more like the others that are in "Standards" mode by default.

The email Microsoft sent me is to inform developers that they're not left in the dark. Microsoft has offered a way to make the sites tell IE to go back into "Compatibility" mode so it will look the same as it would in IE 7 or earlier.

NOTE: This is not an excuse not to fix your markup!!! You still need to fix your sites to be compliant with standards... this will just buy you some time until you do.

Go to Microsoft's article to find out how to use this compatibility tag should you need to.

Make sure to download Internet Explorer 8 beta and see if your sites may need this tag... your site will render differently in IE7 and IE8 if you do; if they look the same, you're a good developer! :)

JavaScript Won't Run on Internet Explorer as a Local File When Copied From Another Computer

My friend Walt was trying to write a little HTML page with JavaScript to automate a task at work for himself and some colleagues.

He developed it on his own computer; saved it and ran it in Internet Explorer (the only browser allowed to be on their computers at work.) On his computer, the page appeared in "My Computer" (counted in the "Internet" zone if you double-click to bring up the security settings.) Internet Explorer prompted him to allow the ActiveX content.

He then put the file on a network share and allowed his colleagues to download it to their own local machines.

When they downloaded and opened the file in Internet Explorer on their local computers, it appeared as "Restricted Sites" zone. This confused both of us, so I asked him to send me the file.

He transferred it to me via Windows Live Messenger and I saved it to my desktop. I got the same result when I opened it in Internet Explorer.

For an experiment, I edited the file... copied all of its contents into a new file I created from scratch on my machine. When I loaded the new file in Internet Explorer, it appeared as "My Computer" in the "Internet" zone as it had when Walt originally created it.

Thus we can deduce that IE must look at the file's properties and determine if a file was created on the machine asking to run it and if not, locks it down as a "Restricted Sites" file. It treats the ones created on the machine in question as "Internet."

While annoying, this is a nice security feature... and now you know how to get around it...
1. Make sure you analyze the code before you copy to a new file - if you don't and you introduce malicious code on your own machine... shame on you and Microsoft did all they could to protect you. Shame on you... :)
2. Copy the code into a new file that you save to your own machine.
3. Open in Internet Explorer

Of course, I don't know that Firefox has the same restriction, because it doesn't allow direct calls via JavaScript to ActiveX objects so it may run just fine without the extra steps... If so, and you have Firefox on your computer; well, you know what to do.

Bug Discovered in Internet Explorer 7 JavaScript Regular Expression Engine

I enhanced my understanding about Regular Expressions' "look-ahead" concept that I hadn't fully comprehended before. The fact that (at least in the .NET framework and most JavaScript engines; I assume it also works in PERL and other popular RegEx engines...) you can use look-aheads to not only find a match but not include in the full-text match; but can look-ahead and not have the position of the start of the match matter either.

For some reason I always thought that the match would be made and the beginning of the next match would start at the position the other left off at. I wet my pants with glee when I found that wasn't the case...

That is, until I tried an expression in JavaScript in Internet Explorer 7.

To see an example of what I'm talking about, run my "Regular Expression Tests for Your Browser" on JavaScriptJedi.com in multiple browsers on your computer. You'll be running the "Pre Match Look Aheads (2008-05-05)" tests which are the only ones there at the time of this writing. I may add more in the future.

The scenario is this:
I had a set of password restriction requirements to enforce on a form when a user wanted to change their password. The requirements were that the password must be at least 8 characters long; contains at least one number and at least one "symbol". Due to a database constraint, I also added a max-length requirement of 50 characters, and I interpreted "symbol" to mean any non-alpha-numeric character.

That said, the regular expression ended up like this:
/^(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{8,50}$/

What's really cool about this is; when run in a properly working regular expression engine, it doesn't matter if the number or "symbol" come first, it will detect them both and then from the beginning of the string match any characters between the lengths 8 and 50. Genius. Whoever came up with Regular Expressions needs a Nobel prize or some equivalent; because, well, they just make a developer's world a better place to live. :)

So after getting uber-excited about my new found knowledge and greater love for Regular Expressions, my bubble was quickly burst when I found out it didn't work correctly in IE7 and I had to come up with a workaround.

So go see my page and try it for yourself; and I'd love to get your feedback on this one. I'll be submitting a bug report to Microsoft (if I can figure out how...) and if I hear anything back from them (which I'm sure I won't...) I'll post my findings here.

I'd especially like to hear from Mac users that can test on the major Mac browsers for me and tell me which work and which don't.