8. Wiring It All Up

Main Points

• AutoEventWireup Details Managing event handling and how AutoEventWireup works.
• Root Relative Paths Working out problems defining root relative paths.
• ^{Skip to Main Points} links return to the Main Points menu.

AutoEventWireup Details

Oh, and did I mention that somewhere along the line I lost the C# code to run the contact form. As a test, I'm adding this to the .cs file for the user control so they stay together. That's the object which uses the email functionality so I decided that was the best place for the code instead of the ASP.NET master page. I hope this is correct. I guess we'll see. It will also be interesting to see if I need to adjust any ids in the code. For now I've pulled the code from the contact form development section and upgraded it to the point that it does not throw errors when building. We'll see if it works when I upload this to the server.

Well, it didn't. Typical, we're used to it, no problem. It looks like AutoEventWireup may not be all it's cracked up to be. For some reason this button wouldn't activate automatically so I was told to add an OnClick attribute and reference the function I wanted to run explicitly. I'll test that, and then decide if it's worth using true at all. I would prefer the consistency of setting AutoEventWireup to false and always specifying which function to run, unless there's some reason not to, and there doesn't appear to be based on the feedback I'm getting. {Except that it absolutely failed to work. [2009/01/21, chroniclemaster1]}

Root Relative Paths

I also discovered that at least part of my problem with using the ASP.NET ~/ root relative paths, is that it looks like they have to be processed on the server side and replaced with the "correct" relative path for output to final XHTML. This does make sense, and I was able to rework the contact form image to work correctly. By specifying the path relative to the root, it would attempt to process the tag if I simply added the runat="server" attribute. However, it broke down because I typically specify image dimensions explicitly, e.g. 150px. The server threw an exception when ASP.NET tried to process that as an Int32 object, so unfortunately I had to remove the px leaving the integer naked. Then it would pull up fine, but the image wouldn't rollover. As I suspected, the rollover javascript function uses a GetElementById function to grab the events for mouseover and mouseout. As soon as I added the ct100_compContactForm_ prefix into the javascript everything worked fine.

Next I tried to add the runat="server" attribute to the link tags in the head and reference the favicon and stylesheet with root relative paths. While it did not throw an application exception, the tilde survived into the output and the page lacked a favicon and a stylesheet. I have hard coded both of them for now. I will need to go to the forums and try to figure out how to accomplish this. Root relative paths are suppose to be one of the great advantages of .NET and I have serious questions about how master pages will work without them.

I hit the forums looking for advice and got: blank stares, sophisticated recommendations for using literals (which are actually really cool and I don't understand why Microsoft is so in love with labels in their demonstrations when a literal renders no extraneous code and labels render a superfluous span tag; unfortunately this did NOTHING for my particular problem), and code snippets for ResolveUrl (which did not actually work in my site and I was never able to get assistance why). I finally found a couple guys on Sitepoint.com which once again turned out to be a godsend. They settled me down. Got me to strip all the fancy stuff out of my code including a user control and a content placeholder. Now I've already been able to put back the contentplaceholder because it doesn't include either of the affected links though I'd like to test adding an extra stylesheet that way. I tried using runat="server" in the link tags again, and again nothing. However, when I tried another guy's recommendation of inserting runat="server" in the <head> tag, it worked! runat="server" in the link tags is unnecessary, just one in the head tag. Phew! So all that's come through.

The same guys tell me however, that pulling the javascript in will be a lot more difficult. If you use a runat="server" in a script tag, .NET assumes you are using a server side script and tries to execute the javascript on the server. You have to use some of the .NET classes to include the script and pull it in. However, I'm not familiar with ANY of those parts of the .NET library so programming against them could be "interesting".