IE7 broke my AxWebbrowser!!!

Today was a rough day.

The application I work on is a click once app, that contains a heavily integrated web browser. At first I went with Visual Studio’s default web browser control, but because of it’s short comings, I went back with the COM component, AxWebbrowser from the VB6 days.

Life was fairly well with AxWebbrowser, until I upgraded to IE7. While it still navigated, i lost nearly all of my event handlers, thus making it worthless. It took quite some time for me to even realize it was IE7 that broke it. I had upgraded weeks ago, and completely overlooked this huge flaw in the system the whole time, thinking it was something completely different.

So, being really under the gun, here’s what little I know. When upgrading to IE7, I lost NavigateComplete, DocumentComplete, and NewWindow2 events. I still had the Enter and ClientResize events. I tried removing the control, removing the automatic handler code, and even creating the handler manually, all to no avail. It never hit the breakpoint.

I was able to find an older copy of AxSHDocVw.dll and SHDocVw.dll in one of my previous projects. SHDocVw.dll was four kb’s smaller and had a different modification date. AxSHDocVw.dll was the same size but also had a different modification date. I tried copying over these new files, and referencing them to no avail.

There’s not much on google about this problem, some guy said enable scripts in IE7, which I thought was crazy but couldn’t find the setting he was talking about to completely debunk it. Some said IE7 developers did this by mistake but offered no help. Other than that, just a lot of confusion and Microsoft complaining. I wonder if Microsoft may be attempting to get a little more secure by cutting out this feature rich browser.

Likely for me, my supervisor had no upgraded yet, so we were able to load the project up and deploy it on his IE6 machine. I am happy to report that IE7 makes no changes to the project, it’s just not developer friendly from an IE7 machine. The client machines running on IE7 or IE6 only have problems when an IE7 machine published the project, the clients browser does not matter.

So, I’m not sure what I’m going to do in the next few days to try to ultimately resolve this. Here’s my thought process:

  1. Try removing IE7 and see if everything is back to normal, a short term and unlikely fix.
  2. Perhaps IE7 while killing AxWebbrowser, finally brought their default webbrowser up to snuff.
  3. Take a serious look at either a Google Chrome component or a Mozilla component.
  4. Pray.

Well, I made this blog to solve tough issues where google fails, me and it’s rare. But like the empty click once message, I was shocked how little information there was out there on this problem. So, I’m posting this as a place holder, if I solve this problem I promise to come back and let you know how I fixed it. If you don’t see an update, you can assume I failed.

UPDATE: Uninstalling IE7 did not fix this. My AxWebbrowser control still does not work. I might as well put IE7 back on.

UPDATE: Checked in to geckofx. Seems like too big of a reference and some complaints about slow start up time. Chrome’s chromiumembedded seems promising but it’s not even in beta yet. Back to the WebBrowser control.

UPDATE: I went with the Visual Studio default Browser, and was able to reproduce what I did in AxWebBrowser, how I did it here:  Goodbye AxWebBrowser

YUI Menu & IE7 – Submenus Closing

Big fan of the whole set of YUI tools (http://developer.yahoo.com/yui/), but recently I’ve had an issue with the YUI Menu. The version I was using is the latest, v2.6.0

I use the YUI menu as a vertical menu, at the top of my web application. The menu and the application are quite extensive.  The menu system I use has the root menu, then when dropping down there are single items and submenus. I never go past a single tier of submenus.

It’s always worked great on my computer, until I upgraded to IE7. Each time I would use it, and try to click on a item in the submenu, the damn thing would close on me. It wasn’t 100% of the time, but well over 75% of the time. I eventually worked out a trick where if I held down the mouse button, and then moved the mouse I could keep the submenu open.

While a very small percentage of my user base is IE7 browser users, I couldn’t imagine what they were going through. It was annoying the hell out of me, and just made the entire application look bad.

After checking it on firefox, chrome, and IE6, I was able to realize it is just an IE7 issue. Unfortunately, I didn’t really find anyone else via google with this same problem.

After playing with it I finally fixed it:

1. I noticed that when the submenu was closing, it seemed to be finding elements behind it.

2. I increased the z-index of the menu. While this did not work alone, I still believe it helps.

3. When z-index didn’t work, I noticed in the documentation this nugget:

iframe Boolean false (true for IE) (Inherited from YAHOO.widget.Overlay.) Boolean indicating whether or not the Menu should have an IFRAME shim; used to prevent SELECT elements from poking through an Overlay instance in IE6. When set to “true”, the iframe shim is created when the Menu instance is initially made visible. This property is only applied when the “position” configuration property is set to dynamic and is automatically applied to all submenus.

4. While that appears to include IE7 in the default, I decided to force it on anyhow.

BAM! Submenu items fixed, YUI menu is wonderful again! No noticeable downside to Firefox and Chrome. Life is good.

First Annual Malen-Link SNES Mario Kart Match

It’s been way too long.

 

One of the best memories of college had to be rediscovering my childhood love, Mario Kart for the SNES. My roommate and I, Malen, would race for hours. We were fairly well matched, although, I do have to give him credit he has a slight edge on me.

Since Mario Kart Wii was due to be released, and the NFL draft was on the TV we decided to get together and race for several hours. The early vegas line a week before put it at malen -4.5 LINK, quickly when news of a finger injury hit the wire, the line skyrocked to malen -8.5 LINK.

I’m happy to say I beat the spread, but was unable to pull off the Appalachian State v Michigan upset.

My favorite moment, was when Malen was about to clinch a cup on the final race. I was in second, he was in first, it was a winner take all race. He began to utter the words of victory as he rounded the final turn, and ran into a green shell a foot in front of the finish line. I, and three computer opponents passed him before he was able to finish the race, giving the cup to me.

Here’s the results:

Total Points: Malen 716 – Link 681

Total Wins: Malen 62 – Link 48

Total Cups: Malen 12 – Link 10.

And if we factor in the spread, Link 18.5, Malen 12.