I created a method that cycles through all of the controls and checks to see if it has the attribute “Required”, and if so, then add the RequiredFieldValidator and Ajax callout controls automatically. You could obviously expand on this to meet your specific needs.
Here is how you would markup your TextBox control:
<asp:TextBox Required=”true” ValidationGroup=”valGroup” ID=”TextBox1″ runat=”server” />

Here is the method in the code behind:

private void AddRequiredValidations(ControlCollection controls)
{
    List requiredValidators = new List();
    for (int i = 0; i < controls.Count; i++)
    {
        if (controls[i] is TextBox)
        {
            TextBox tb = (TextBox)controls[i];
            if (tb.Attributes["Required"] != null && Convert.ToBoolean(tb.Attributes["Required"]))
            {
                RequiredFieldValidator requiredValidator = new RequiredFieldValidator();
                requiredValidator.ErrorMessage = "Required";
                requiredValidator.ID = "required" + tb.ID;
                requiredValidator.Display = ValidatorDisplay.None;
                requiredValidator.ValidationGroup = tb.ValidationGroup;
                requiredValidator.ControlToValidate = tb.ID;
                // Add the RequiredFieldValidator to a list to be added later
                // Since we can't add them to the control as we are cycling through them
                requiredValidators.Add(requiredValidator); 

                tb.CausesValidation = true;
            }
        }

        if (controls[i].HasControls()) // If this control has child controls
        {
            AddRequiredValidations(controls[i].Controls); // Search the child controls too
        }
    }

    // Now we can actually add the RequiredFieldValidators since we are done cycling through the existing controls
    for (int i = 0; i < requiredValidators.Count; i++)
    {

        AjaxControlToolkit.ValidatorCalloutExtender callout = new AjaxControlToolkit.ValidatorCalloutExtender();
        callout.TargetControlID = requiredValidators[i].ID;
        callout.ID = requiredValidators[i].ID + "Callout";
        controls.Add(requiredValidators[i]);
        controls.Add(callout);
    }
}

Then all you have to do is call it in your Page_Load() method:

AddRequiredValidations(this.Controls);

This will work not only for a singe TextBox control, but also for TextBox controls buried inside a GridView or Repeater!

<ajax:ListSearchExtender ID="lseAjaxDdlFilter" runat="server" TargetControlID="ddlFilter" IsSorted="true" PromptPosition="Top" />

When debugging the issue, I would find that it would save and get the correct scroll position from the cookie; however, when setting the scrollTop:

document.getElementById('myDiv').scrollTop = scrollPosition;

It would not set.  The DIV’s scrollTop would be 0 before and after the statement above even after verifying that scrollPosition had an actual value!

I will also mention that the grid did have a decent about of data.  Actually, enough to make the page size about 3.5 MBs by the time HTML was rendered…almost 1 MB taken up by ViewState alone!  Because of AJAX and the amount of data in the grid, there was a noticeable amount of lag when using the page…not a lot, but noticeable.

Work Around:

I started to wonder if the above javascript (which ran on window.onload) may be running too quickly…or rather, ran before IE could finish with the rest of the AJAX/javascript code on the page.  So I tried this line instead of the one above:

setTimeout(function() { document.getElementById('myDiv').scrollTop = scrollPosition; }, 250);

So basically, I wanted to wait 250 milliseconds before setting the scrollTop.  Much to my surprise, this worked!  By this point I was too exhausted to keep knocking down the delay to see how low it could go and still work.  I couldn’t really notice the 250 delay in setting the scroll position, so that is where I ended.

Your mileage may vary, but in case you have a similar issue…try a small delay when setting the scrollTop before attempting to re-engineer the whole page.

The company needed to track time logged to particular jobs/projects.  The initial idea was to use a site like ClickTime.  However, for an employee to log time against a job, you would need to tell ClickTime all of your jobs (which would be tedious) or configure an integration app to automatically populate the available jobs/projects.

Solution

I created a web application that would allow employees to log time against jobs/projects.  It would search instantly against their project management software for a list of available jobs.  The type of work was categorized for reporting.  Since we would have the employee’s hours, it would be used for payroll.  I implemented an export feature for preparing the payroll information for ADP and EDH.  Work time for each project was then entered into the project management software to be calculated as job cost.  As a bonus, you could use the gathered data to calculate each employees “utilization”.

Landing page.	Enter time for a particular project/job.
Apply costs to each job.	Payroll export options.
Utilization

This project had a similar background to the Install Schedule application.  We started using a software package called eManage (I worked for this company later and built a mobile web application to interface with their database) to manage several areas of our business.  The software has a built in calendar that can be used for scheduling installations.  The look and feel of the calendar is very similar to the Microsoft Outlook calendar.

Problem:

Our employees were accustom to the layout of the Install Schedule application.  They liked each installer to have its own line, doing it that way also makes it easier to manage employee’s time too!  It was not possible to change eManage to show the calendar this way.

Solution:

Build a separate web site application that will have the look and feel of the Install Schedule, but pull its information from the eManage application.  Job assignments and modifications will be made from within the eManage application and those changes will be reflect instantly on the web site.

Result:

Fig. 1

Fig. 2

Fig. 3  

The web site pulls data straight from the eManage database so the info is always live.  It also provides the installers and coordinators a familiar look to the schedule.  Each user has their own user settings which allows you to view the installers that you want to view and customize the size of the calendar to fit your particular screen resolution.  Fig. 2 shows that you are able to click on a job to expand the bar to see all of the information.  The color schema for the jobs are the same as they appear in eManage.  Fig. 3 shows the "Jump to Date" which utilizes a modal popup screen.

One of the many things my company does is file room conversions.  To make this short and sweet, a file folder may need to be moved to a new location.  In the process the folder may need a new label applied to the folder.  This is simplistic example of a conversion.  A client requested this type of service from us.

Problem:

This was a large conversion and the client required several specific "checks" to be in place.   The original folder needed to be scanned by a barcode reader to rule out data entry errors.  The barcode data would then need to be sent to the client so that other various information could be added.  The data would then need to come back to us so that we could print new labels.  Since this was a daily process for approximately 3 months, some tracking was needed so that at any given time a folder could be found.

Solution:

I was to create several applications to aid in the conversion process.  Starting with one to handle the barcode scanning in the first stage.  Next a secure web site needed to be created to allow files to be received from scanning, downloaded by the client, and re-uploaded.

Result:

Fig. 1

Fig. 2

Fig. 3 

I created 2 desktop applications and 1 web application that included a web service.  The first desktop application was installed on laptop with barcode scanners attached.  This application would be used to gather file label barcode.  Fig. 1 show the screen of the laptop with the application running.  The screen provided various information and also included visual and audible verification of scanned barcodes.  Because of the barcode situation on the folders, the application needed to check to make sure the barcode was in fact valid. 
I provided 2 different way to get the scanned data back to the main office.  One way was by using a web site upload utility.  The other way was to have the barcode scanning application automatically send the file via a web service that I created.  Either way, the file was placed in the same folder back at the main office.  This folder was being watched my another desktop application that I made that ran on a separate machine.  Once a file was uploaded, the desktop application would grab the file, import all of the data into a SQL Server, and post the file on the secure web site where the client could download the file.  The client would add various information to the data and re-upload it via the web site.  Date and time stamps were noted of all of the transactions.  The re-uploaded file was placed in a different folder that was also watched by the desktop application.  Once this file was uploaded, it was checked for certain required data, checked for the correct sort order, imported into the SQL Server, and marked as "OK" so the client would know that everything was good.
Up until now, everything was automated and only required routine checkups to make sure everything was okay.  The last step was to print out the labels (sample shown in Fig. 2).  The step to print the labels was simplified into dragging and dropping the file that was re-uploaded from the client into a separate watched folder.  Once the file was dropped there, it was sorted into a special sort order since their sheets were later to be cut into single labels.  Then a cover sheet was printed followed by the label print job.  After the labels are sent to the printer the printed date and time is noted in the database and viewable from the web site.
Fig. 3 show the landing page of the web site application which allows access to several tools and lookups.

My company uses Sprint as a cellular provider.  Paper bills are 300+ pages and arrive in a box.  Sprint offers a service to download cell data at the end of each month (for a cost).

Problem:

Flipping through the bill was very cumbersome and took sometimes several hours.  My company wanted an easy way to look at the employees usage.

Solution:

Utilize the Sprint service to download data each month.  Load the data into our own SQL Server.  Create a web site to summarize that data while providing a simple user interface.

Result:

Fig. 1

 Fig. 2

I created a basic web site to simplify the cell usage data.  You can search by bill cycle or a specific data range.  Users that use more than 1,000 average billable minutes per month are highlighted in red.  Clicking the specific user will show the call details.  Fig. 2 shows the Detailed Usage page which also allows you to highlight mobile to mobile, text messages, nights, or weekends.