The simplest thing that could possibly work - My Iron Coder Entry is up on Project Distributor

My entry into our little “Iron Coder” competition is up on Project Distributor. After Darren’s entry explored the observer pattern with a nicely factored interface for “secure” controls I thought there wasn’t much left for me to say in that direction. Instead I tried to do the simplest thing that would work - sub-classing the tab-page control, adding a roles property and ensuring the tab-page was not displayed (by removing it form the parent tabstrip’s tabpages collection). »

Exciting move for Patrick

I’ve had to keep quiet about this ‘cause he hadn’t told anyone but my brother Patrick is off to the pacific north-west to work on developer tools. The persistent drizzling rain of Redmond would be hard to acclimatize too, except that he’s been living in London for the past few years so probably not much will change. Apparently he’ll be starting around the same time as Dominic, who is joining the office team (which he previously interned with) on a secret project about which he has refused to divulge anything. »

Extender Provider vs. Subclassing Bake-Off

Mitch has replied in our ongoing discussion on the merits of extender providers, and suggested a “code-off” to test out the merits of the two approaches. I think that’s a great idea. Mitch - I’ll let you define the a hypothetical scenario (and maybe some starting code) and we’ll go from there.(note to self: Mitch is going to kick your ass…back out now….back out) And now to continue the discussion:

Mitch says “Sub-classing has one advantage over extender providers in that by using the derived-class you automatically get the modified behaviour when you drag the control onto the design surface for the first time”. I think one of the benefits of sub-classing (if you’ve used that approach from the outset) is that you can make broad changes across your whole application from a single place. While this can be a sharp and useful tool it can also be a good way to cut off your hand (if not used appropriately). If you decide you want to add something with extender providers you have to go and add the provider to all the forms, then set the “extended” properties on all the controls. For applications with hundreds of forms this could be a little annoying. Also (and this is nit-picking a little) debugging “design-time” behavior can sometimes be annoying and a little more tricky than just plain inheritance. Ultimately the decision to use extender providers or subclassing isn’t and exclusive one, you can use either approach where appropriate.

Back to the discussion of a code-off for a minute: Does anybody think this would be a good thing for codecamp OZ next year? I’m thinking something like Iron Chef - “The challenger hails from a small consulting company in <big city>. Noted for their clever use of delegates and encyclopedic knowledge of the System.Data namespace. Who will they face? Will it be Iron Coder VB.NET Mr Bill McCarthy? Iron Coder Integration “Biztalk” Bill Chesnut, or Iron Coder Regex Darren “bracky” Neimke?” I love that crazy “Chairman Kaga” from the Iron Chef show. From his interesting “philosophical” out-pourings at the start of the show to the way he bites into that yellow capsicum and then looks at the camera. I aspire to that level of craziness.
Chairman Kaga biting into an capsicum

Comments

Greg Low
Hi Joseph,

Now that post’s got "blog entry of the week" written all over it but the new week is young as yet…

Regards,

Greg
8/07/2005 3:22:00 AM

»

Mitch is tightly coupled to extender providers

Mitch has been thinking about extender providers vs. sub-classing of GUI tool-kits as a result of some internal mailing-list discussions. Here are my thoughts. Firstly the reasons discussed for using sub-classing were 3-fold: A place to make “global” changed to the behavior of an item (change style to “flat”, fix memory leak or rendering problem) Create an “adapter” to reduce the surface area of complex controls, make API more familiar etc Remove coupling between application and underlying tool-kit (allowing you to potentially [1] swap something else in if the first one doesn’t cut it) Extender providers are a way of applying a “cross-cutting concern” or “aspect” to a series of otherwise un-related or loosely related controls. »

Hi, My name is Joseph, and I'm a Boing-Boing Addict

How can you not love a site that brings you gems like these:

Philosophomon: great philosophers’ heads on Pokémon bodies

Bandages that look like bacon rashers

“The Monkey Steals The Peach“ A martial arts killing move involving scrotum removal

A visual history of whispering imps on magic posters

And these are just some of my favourites from the last couple of weeks….hours of my life are wasted reading this stuff. Hardly a day goes by where I don’t see something jaw-dropping.

Comments

Greg Low
Hi Joseph,

Yep, people can waste their whole lives on this stuff. I particulary used to like the people that maintained a daily diary for the Clinton’s cat, while Bill was in office. They published it each day like a newspaper publishes the GG’s schedule for Canberra.

Hmmmmm

Regards,

Greg
6/07/2005 7:01:00 AM

»

If not schema, then what?

John Cavnar-Johnson recently wrote about the shortcomings and contradictions he percieves in the [DataContract] way of annotating types to create messages in Indigo. Although I don’t know if he’s right (and I suspect only time will tell) thinking about the issues he raises led me think more deeply about some aspects of messaging-based systems than I had before. Specifically in the “If Not [DataContract], Then What?” section he asserts that  designing messaging systems starting with Xml Schema is a bad idea because the inherent mis-match between the . »

VSIP MPF makes tasty dogfood

I’ve been “playing around” with VSIP and the Managed Package Framework for a week or so now, with mixed feelings. The API has (what seems to be) an extremely steep learning curve, I’m not a COM or C++ programmer so the API feels fairly alien to me, and I’ve had to go delving through the registry more in the last week than I have in the last few years. On a positive note though I noticed the Xml editor and Xslt debugger for VS 2005 are both written in managed code (with the Xml editor using the MPF). Internal use of stuff by Microsoft generally correlates with better quality so this is encouraging. In the Xml editor implementation surprisingly very few of the classes are sealed, potentially allowing you to “extend” the Xml editor by normal inheritance (altho sealing of classes often occurs later in the development cycle, so some stuff could be sealed up in the RTM that is not now).

Right now I’m wrangling with the CreateLineMarker method if the IVsTextLines interface, and wondering why it always returns a large negative result. Disturbingly a search for CreateLineMarker in Google show a large number of results from pre-marital counselling services. Is my marriage headed for the rocks? Or is it the weblog of Dr Ex (ex for extensibility, not ex as in former) and his post on implementing custom text markers the cause of it all?

Comments

Michael K. Campbell
"The API has (what seems to be) an extremely steep learning curve, I’m not a COM or C++ programmer so the API feels fairly alien to me, and I’ve had to go delving through the registry more in the last week than I have in the last few years."

Agreed. The docs state that just about everything can be done in managed code that can be done non-managed. Only there doesn’t seem to be a whole heck of a lot available in terms of anything to back that up.

Playing around in there gives you the sense that it’s VERY comprehensive, but really not ready for prime-time managed manipulation – $10 says all of the VSIP partners out there adding their own extensions are doing them in non-managed code. (Case in point: Intellisense, looks like the only way to extend intellisense is via the Babel APIS - no MENTION of the chance to interact with Intellisense via something as simple as the Automation Model (or through any other managed interface))



2/07/2005 11:26:00 PM

»

Savas joins indigo team

Savas Parastatidis is joining the indigo team. I wonder if this is an indication of interest in his work on SSDL? »