Rory Primrose

Learn from my mistakes, you don't have time to make them yourself

View project on GitHub

Getting nested ASP.Net control designers to render

Last week, I posted about how nested control designers in ASP.Net were not rendering. I have progressed a lot in the last week regarding getting good support for controls in the designer. No doubt some articles will follow.

With regard to nested designers getting called, this will only happen when the control related to the designer is hosted in an editable region.

The page for example is the classic editable region. You can drag and drop controls onto the page. You can select the control and change its properties through the property grid. Controls themselves may also have editable regions if their designer has been developed to support them.

Read More

Publishing embedded resources in ASP.Net 2.0

I put up a post a while back about my issues with publishing embedded resources from an assembly with ASP.Net 2.0. Ramon wanted a sample, so here it is.

There are a couple of things to note about getting this to work:

  1. The resource must be marked as Build Action = Embedded Resource
  2. Line 18 in ResTest\ResTestLib\My Project\AssemblyInfo.vb must include the full namespace of the assembly, not just the filename of the embedded resource
  3. As above, Line 21 in ResTest\ResTestLib\ResTestControl.vb must also include the full namespace of the assemlby, not just the filename of the embedded resource
Read More

Nested Whidbey ASP.Net control designers

I have been designing and building a nested set of web controls over the last couple of weeks. By nested, I mean that there is a parent control that contains a set of child controls of a specific type.

I like to have default behaviours of my web controls in the designer when they are empty. For example, the parent control would add 3 child controls if it was empty and the child control would display something if it was empty, like how the label displays “[ID]” when the text property is empty.

One thing that surprised me was that the designers for the child control don’t get called when rendering the parent control in the designer. This means that the behaviour of the parent’s designer must also do the designer work of the child control.

I am sure this is not right. One of the reasons I think I am missing something here is that if I take the panel control (which has a designer), and I put my own control in it that has a designer, my controls designer gets called. Why would it be different with two of my own nested controls?

I hope I am missing something because the nested controls should be calling their own designers to help with design-time rendering rather than relying on parent controls which would typically be completely unrelated (the panel isn’t going to understand how to handle an empty label control).

I will have to check my code again.

Read More

Generally speaking, name collisions are bad

I have been developing some Whidbey web custom controls for the last couple of days. I have been getting a little frustrated with what looked like (and probably still is) bugs in the designer.

I have been creating a custom tabbar control. Let’s call it MyNamespace.Tabbar. I have designers, builders and converters to improve the designer support. Most of the time, the designer support just doesn’t work. Sometimes I get a great error saying that MyNamespace.Tabbar can’t be converted to MyNamespace.Tabbar. Given that both the assembly’s namespace and System.Web.UI are imported, I probably have a naming collision on the control.

Parts of the framework are still able to determine that I am referring to my Tabbar class rather than the System.Web.UI.WebControls.Tabbar (given the error message rendered in the designer), but elsewhere, it can’t follow through (hence the error). BTW, at runtime, none of this is a problem. Interestingly, even when I clarified the declaration with the full namespace, it still fell over in the same spots in the designer.

After a name change, it is all fine.

Read More

Fix the BASE tag, break me

The IEBlog has just posted an entry about the behaviour of the BASE tag in IE7. The standard (back to HTML 3.2) says that the base tag should occur once in the document and it should be located in the HEAD tag. The IE implementation for the last few versions has been that references and links will be relative to the last BASE tag specified. IE7 will remove this behaviour to be more standards compliant.

While I agree with standards compliance, this one will hurt. I have built a feed reader application that displays entries that have been obtained from different sites. It is quite common that when people write their blog entries, they include relative references to images and hyperlinks.

I have used the IE BASE tag behaviour to get around the broken link problem that my feed reader would otherwise have. For each entry that I render from XML to HTML, I prefix it with a BASE tag that specifies the base href being the url of the web version of the post. As any relative image and anchor urls would be relative to that page, my feed reader was causing IE to correctly identify all the resource for the entries regardless of the site they came from.

How do I get around this? Any ideas?

Without any nice implementation provided already, I will have to parse the contents of each entry, determine the links that are relative and prefix them with the web address for the entry. Quite ugly.

I don’t mind if they revert the BASE tag implementation to be more standards compliant. It would have been nice if the IE team provided another way to declare a section of HTML as relative to a base url though.

Read More

Interfaces or Inheritance

I have been thinking about this a bit recently. When is it the most appropriate to use an interface or inheritance? There are so many advantages and disadvantages with both.

Not that I can go to his talk, but I liked a few of Doug’s comments on the matter.

Interfaces are better for those places where extensibility is the highest requirement. Inheritance is better for those places where reusability is the highest requirement.

You can screw up your software by doing too much of either one, or by neglecting either one.

A couple of weeks ago I was building a queueing system using generics. The main problem I had was that I wanted a little bit of functionality in the queued item, so I wrote a base class for it. That was all well and good, but then I quickly realised that most of my objects already have a base class. As you can’t have multiple inheritance, there goes that idea.

To get around this, I have to change the implementation to use an interface instead. This isn’t a bad thing, but to get the same functionality there will probably be a performance hit. This is because the queue would need to constantly check with eached queued item for its progress status rather than the queued item notifying the queue when its progress status changes.

Other than the performance consideration, I don’t like the interface solution so much because the queue will have to assume that the queued item correctly uses the interface. An interface will ensure that an object has the right signatures, but not whether the code in the implemented interface of the object does what is intended.

Any thoughts?

Read More

Pen spinning

Did you ever want to know how to spin your pen?

I have been doing it since I figured out a couple of ways in high school. One of the guys at my new workplace has pointed me to this site. will help you spin with the best of them.

Read More

When a bug isn't a bug, but still requires a workaround

I have been playing with Whidbey ASP.Net over the last week, developing some web custom controls that need to publish some resources along with the control.

I have previously written an article about how to publish resources from the controls assembly in 1.1. This works really well, but requires you to do the resource extraction and HTTP handling yourself. This isn’t a huge problem as most of the code can be reused and is compiled into the resource, therefore very portable. The big problem with it is that after the assembly is referenced by the web project, there is a little bit more work to do to get it working. The developer has to add the httpHandler to the web.config so that the site knows how to intepret the request for the resource.

Read More

Debugging Windows Services

I built a windows service application for work as a piece of my latest projects large puzzle. One of the annoying things about developing windows services is that debugging them as they start is a big problem. My windows service didn’t suffer from this because it didn’t do anything straight away which gave me time to get my fingers hooked into it. Other people at work however did get their service to start work immediately. Debugging their application caused them no small amount of grief.

Paul Ballard just posted an entry (following on from Mike Diehl’s post) about how to debug windows services from the start. Well worth the read if you have been bitten by this.

Read More