Posts Tagged ‘IE’

Cool Tools 8: IEWatch

Monday, August 2nd, 2010

You know what I like about Integryst’s Cool Tools feature?  You guys always have great alternatives to the specific problems these tools solve – the Cool Tool feature of Benthic’s Golden drew more comments than any other post, and they were all great!

I’ve profiled header tools before (FireBug is an obvious one), but I haven’t profiled any IE header/debug tools yet.  I’ve used IEInspector’s HTTP Analyzer before, but for the love of all that was Holy and Mighty, that thing crashed IE more often than a WebCenter Consultant on a 24 hour code bender (didn’t see that one coming did you?  yeah, I’m not funny).

So, today’s profile is for my latest IE header tool of choice: IEWatch’s IEWatch Professional.  It’s not cheap at $169, but at least it’s not as bad as HTTP Analyzer and doesn’t fold like a cheap suit (yeah, i don’t even know what that means.  i’m not funny.).  The tool is straightforward:  install it and choose View: Explorer Bars: IEWatch from IE’s menu, and you’ve got a slick header tool that gives you a decent snapshot of what IE is doing behind the scenes, showing requests, responses, post data, and pretty much everything else you need to diagnose a poorly performing ALUI portal…

So here’s my question – given that HTTP Analyzer is cheaper, but has more bugs than this place (sheeeesh!  i TOLD YOU i wasn’t funny!), what IE header tool do YOU use?

Cool Tools 6: IE Web Developer 2

Thursday, June 24th, 2010

After upgrading from ALUI 6.1 to WCI 10gR3, all of our portlets looked … wrong.  The background color had reverted the blue, and they were cutting off on the right side so you couldn’t see the toolbar buttons.  Strangely, this was only happening in IE, so we weren’t able to use Firefox’s FireBug.  Fortunately, there’s a similar type of tool offered by IEInspector Software called IE Web Developer 2.

Similar to FireBug, it offers basic HTTP tracing, JavaScript debugging, and, in this case, DOM/CSS analysis.  This allows you to higlight an item on the page – in this case, a portlet – and view all the styles applied to that item.  it also shows you where the style definitions are coming from:

Using it, we were able to determine that the CSS files had changed, and there was an addition of “table-layout:fixed’ and a ‘background-color’ definition in the CSS definitions for the column layouts.  Removing these definitions from the CSS restored the look and feel back to the way we had prior to the upgrade.

How did we update the hundreds of CSS files we had?  Well, that’s a post for another day… (more…)