Matthew Knott

I’ve been trying to create two webparts that communicate with each other in SharePoint. Looking around the web there are a number of good examples of how to create an asp.net 2.0 webpart that communicates with another but there are a couple of things that they don’t tell you.

Develop your webparts in one project

If you want your webparts to be able to talk to each other, you have to develop them in the same project in Visual Studio, otherwise they won’t compile. Sounds obvious enough but no-one ever actually says to do this.

Once you’ve built the provider webpart, simply add a new webpart into the solution explorer and off you go.

Linking the webparts

Another thing that is never covered for SharePoint is how to link the webparts once they’ve been developed. Firstly, click edit page, and then click the edit button on either the provider or the consumer webpart.

From here you will see connections, select send ... to, or get ... from, depending on which webpart you’re looking at. Once this relationship has been established, your webparts should communicate perfectly.

Tags: Microsoft Web ASP.NET SharePoint Webpart Part Communication Communicate Link 2007 Develop

The HTML equivalent of an Anderson Shelter, a meta tag that makes IE8 render websites in an IE7 compatibility mode, has been released by Microsofts Nick MacKechnie in his blog this week.

I'm not sure whether I should say "thanks for the heads up" or "why the hell should I have to?". I mean, my site is standards based, I specify my doctype, and there should only be one way of displaying that document.

So yet again, after spending years slowly adopting web standards, Microsoft has yet again come out with a version of internet explorer that adds their stubborn feature set, prioritised above features that make it easier for developers to develop cross-browser compatible sites.

I really did think that this was Microsofts chance to build on the progress they had made with IE7, but no such luck. A couple of months ago I tried out IE8, and when I hit IBM's W3 intranet, All I got was a little blue bar at the top of the page, and nothing else. The majority of sites I've looked at with IE8 do not handle well, so this meta tag is going to be compulsary.

Perhaps Microsoft should absorb the cost that will be incurred by local business to have this line of code inserted into every page of their website, there bust be billions of pages of markup that will require changing, so profitable times ahead for web developers.

Tags: Standards Microsoft Web_Standards IE7 IE8 Developers Selfish Doctype W3C Stubborn

This article really encapsulates a lot of the things that frustrate me about Microsoft's "I know best" attitude to it's web browsers. The purpose of the W3C Standards is to facilitate a common experience across all-platforms and browsers.

This site is something of an ongoing project for me, I've tackled advanced apache configuration through my work with mod_rewrite, cloud trees, which were mild challenges, but nothing compares to the sheer hair-pulling that comes from trying to get your site looking good cross-browser. This site, for example, great in Safari, Firefox, Internet Explorer 7, and Opera, yet I have margin issues in Internet Explorer 6.

This is frustrating as a developer because it means valuable time is wasted trying to flush out happy mediums, often forcing compromises on excellent designs.

IE 7 represented a step forwards in terms of compatibility, but there is still a long way to go before developers can rest assured that their site will look the same in each and every major browser.

My particular problem related to the infamous margin-doubling bug in IE6 when working with floated elements. This is documented in numerous websites, and the recomended fix is to use display: inline.

This resolves the issue, although totally against W3C guidelines. Plus, if you're using an element that requires the display property to be set to block, you have even more tinkering to do that will probably force you to deviate further from the set standards.

After some experimentation, I found that the display: inline-block existed, fixed the bug, and retained the properties of a block element insofar as the padding etc was still correct.

Tags: Standards Browsers Microsoft Design Safari Firefox Opera IE Internet_explorer css inline-block inline display property