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.
I have used XML queries in SQL Server for several years now and I am very impressed with the changes to FOR XML in the latest SQL Server 2005 beta. Unfortunately, there doesn’t seem to be much changed in the OPENXML arena.
I was working with an OPENXML statement the other week and I was sick of writing WITH clauses to define how to interpret the XML data. I looked at the documentation for the WITH statement and discovered that you can specify an existing table and use its schema to interpret the XML.
This was great news as I shape my XML data in a way that is consistent with the table schema that stores the data in the database. I wanted to just specify the table that the data was related to. This prevents having to manually type the schema in the WITH clause and also means that if the schema of the real table changes, namely field size or type changes, the procedures don’t need to be updated unless fields are removed or added.
For the last couple of days at work, I have been developing a new ASP.Net site. Across all the pages in the site, there are some common methods and properties that need to be used. In the case of this new application, I needed to check if the authenticated user has permissions in Active Directory to see the details of the user they are requesting.
The easiest way to achieve this common functionality is to create a base class that inherits from System.Web.UI.Page. Each WebForm code behind page can then inherit from the custom class instead of the default System.Web.UI.Page class. I hit some interesting problems with developing this solution in the VS IDE.
The main purpose of creating controls is so they can be reused in other projects. The beauty of Web Custom Controls as opposed to Web User Controls is that they are compiled into an assembly which can easily be copied between ASP.Net projects.
Take an image for example. What happens when a control needs to render an image to the browser? It needs to render some HTML like <IMG src= ‘test.gif’ />. The browser then makes a request to the web server for test.gif. Thats all very well and good, but to deploy this control, you not only need to copy the controls assembly to the deployment bin folder, but also need to deploy test.gif to the correct folder to be requested by the browser. Each dependency of the control needs to be copied across each of the ASP.Net projects that use the control. This very quickly becomes a maintenance problem.
We had a Tae Kwon Do graduation this morning. My wife and I both completed a double grading to go to a Green belt. We are now at the start of the intermediate ranks.
I have seen scripts developed as hard-coded strings in a controls code too many times. Sometimes when I see these hard-coded strings, the developers are at least using a StringBuilder object. StringBuilders make large amounts of string concatenations very quick. They also tend to cause the developer to construct the string contents in a line by line fashion. Scripts built as hard-coded strings are not usually very large so any performance benefit gained from using a StringBuilder would be negligible, but better formatting of the code from a line by line style is easier to read.
Regardless of whether a StringBuilder is used or not, building up a string is clumsy as it makes the script really difficult to develop and even harder to maintain. A better way of developing a script for a control is by adding a script file to the project and rendering the contents of the file to the browser. In doing this, developing and maintaining the script will be easier as you will be editing the code just like any other text based file.
My wife and I started doing TaeKwonDo about six months ago and it has been a lot of fun doing it together. After only three weeks, we were able to do a triple grading to take us from White belt to Orange three tip. Since then we have done a double grading to go to Yellow two tip. The next grading is in a week or so. We will be able to go to Yellow three tip, or maybe double grade again to get to Green belt.
I have now been asked if I want to become an instructor. After several weeks thinking about whether I would be able to fit it in, I am going to give it a go.
Over the last couple of months, I have been developing a new skinning engine for the new versions of my applications. To help me test the new skin object model, I have created a skin builder application that relies heavily on the property grid control.
I quickly found that I didn’t like the default support for bitwise enum types in the property grid. For these enum types, the property grid uses the normal drop-down list and allows for only one item to be selected. This means that if you want to set multiple values, you have to manually enter them in the property grids textbox.
I thought that a better way of doing this would be to use a CheckedListBox control instead of the normal ListBox control in the UITypeEditor. True to my style, I rushed in to coding it, only to find out that several other people have done it. It was fun, but with my lack of time, I should have checked Google first. In any case, to maintain some sense of worth and satisfaction, instead of throwing away my code, I made it better than the examples I have seen so far.
Take my (work in progress) ImageButton control from the previous articles for an example. When the user clicks the button, a script will need to run that will determine if the button should have a toggle behavior and how the button should render itself with its defined set of images. This code must always run as it is part of the controls intrinsic behavior.
The implementer of the ImageButton control may also want to run their own script when the button is clicked. If the implementor can’t run their own code on the client, then the control will only be useful as a server control that fires a click event on the server. I want the implementor to be able to run their own function when the onclick event fires, and also allow them to stop the postback as required.
Metadata attributes are attributes that are assigned to classes, variables, structures, enums, procedures, functions and properties (and no doubt others that I haven’t come across). They are usually used to inform the IDE how to handle the objects that the metadata attributes are assigned to. They can also be used by run-time code to handle additional information.
Metadata attributes are defined on items with an < > combination before the declaration of the Item. For example, defining Category and Description attributes to a Text property would look like this: