Reminder emails were needed to be sent out to remind sales staff to follow up on projects.

Solution

I developed a simple command line executable that takes 1 parameter which is an XML file.  The contents of the XML file would look something like:

<?xml version="1.0" encoding="utf-8" ?>
<Settings>
	<ErrorEmail>
		<Email>email@gmail.com</Email>
	</ErrorEmail>
	<SummaryEmail>
		<Email>email@gmail.com</Email>
	</SummaryEmail>
	<Query>
		SELECT * FROM Projects
		WHERE Cancelled = 0 And Completed = 0 AND BookDate IS NULL
		AND FollowUpBy <= getdate()
	</Query>
	<SQLConnectionString>Server=SQLServer;Database=MainDatabase;Persist Security Info=True;Integrated Security=true</SQLConnectionString>
	<TemplateEmailFileName>EmailTemplate.txt</TemplateEmailFileName>
	<EmailSubject>Alert Email For Project#<:ProjectID:></EmailSubject>
	<EmailDomain>mycompany.com</EmailDomain>
	<ToAddressDatabaseField>Salesperson</ToAddressDatabaseField>
	<ToAddressFieldIsEmail>0</ToAddressFieldIsEmail>
	<SMTPSettings>
		<SMTPServer>smtp.gmail.com</SMTPServer>
		<EnableSSL>1</EnableSSL>
		<RequiresAuthentication>1</RequiresAuthentication>
		<Username>email@gmail.com</Username>
		<Password>*******</Password>
		<Port>587</Port>
		<FromAddress>email@gmail.com</FromAddress>
	</SMTPSettings>
	<LogFileDirectory>Daily</LogFileDirectory>
</Settings>

The command line executable would then run the query (<Query>) against the supplied database in the XML file.  For each row returned, the program will send out an email to the user.  Which user?  What email?  The recipients email address would need to be one of the fields returned from the query and noted in the XML file in the element <ToAddressDatabaseField>.  The template for the email body is supplied by the <TemplateEmailFileName> element.   To make the email custom, it is possible to insert fields returned from the database into the email template.  For example, lets say the query returned a field called “FirstName”.  In the email template text file, you could have:

Hello <:FirstName:>,

When the program ran, it would swap “<:FirstName:>” with the contents from the database.  This is similar to a mail merge for emails.  Since all of the values are configurable in the XML file, the usage possibilities are unlimited!  Let say you needed to run this once a week, no problem.  Set up a Windows Scheduled Task to run the executable at the specified interval.

My company wanted to standardize the email signature for all of the employees.  The signature was to contain images and links.

Problem:

Creating a signature in Microsoft Outlook that contains images and links is not the easiest thing in the world.  Not to mention having everyone in the company try to create their own, they would never end up being standardized and turn into a nightmare for training.

Solution:

The  solution was to create a simple desktop application that helps the user create their Outlook signature.  The basic template for the signature would originate from a central location so that updates would be easy.  The email signature also contains a header that is placed at the top of the email.

Result:

Fig. 1

Fig. 2 

I created a simple desktop application that allows the user to enter their specific signature details (Fig. 1).  When you hit the “Create Signature” several things happen.  First the email template is downloaded from a specified FTP site.  I choose FTP so that the application would work when the user was at home connected to the Internet.  Next the program inserts all of your specific info the template.  Then it saves the signature files in the appropriate folders where signature and theme files are kept.  Yes, THEME files too!  Since my company wanted a header image at the top, I had to use a theme for the template.  If I had kept everything as a signature it would always insert 3 lines at the top (that you would have to delete for every email) and spell check would not work (since Outlook does not spell check your signature).  The final step the program does is set Outlook to use the new theme for new emails and the signature for all forwards and replies.  Why not have the theme set for all emails and not even use a signature?  Outlook only uses the theme for new emails…not sure why, but that’s the way it is (or was at the time).  The program can be ran multiple times incase updates need to be made to the signature.  (For example, we did a Happy Holidays theme that we ran for a few months.

As for any company, physical inventory time is never fun.  Our inventory software did not have a good interface for doing this.

Problem:

The process of taking physical inventory was long and tedious.  The process typically involved printing our a huge list of parts, write in the quantity next to the part, then someone would enter that info in an Excel spreadsheet so that it could be imported back into our inventory software to reconcile.  Another issue was finding the inventory items themselves, most items were organized well, but some could only be found by the "one guy" that knows where everything is located.  Identification of parts and part numbers was needed.

Solution:

The solution was to create a desktop application that could be used to take physical inventory.  The application would search against our existing parts database and store inventory quantities in a separate table that could later be reconciled.  The application would also print out a part identification label on a thermal printer that was to be placed on the shelf of each item.  This would make subsequent physical inventories much easier.

Result:

Fig. 1

Fig. 2

Fig. 3  

I created a desktop application the keep track of inventory.  The application also has the ability to print out part identification stickers on a thermal printer that included part information along with a barcode.  Fig. 2 shows the part detail screen.  You can find out various information from the Detail screen as well as adjust inventory levels.  You can pull up a part by either searching by part number or scan the corresponding barcode the program had previously printed out.
The application was such a success, I created a web interface to allow certain other employees access to inventory levels.  Also various reports were created that were needed Accounting purposes.

I created a single page web page that was set as the background using the Active Desktop function of Windows XP.  This web page allowed you to search the employee database for phone numbers or extensions.  It also had a section to calculate shipping for certain items my company sells.

Problem:

Active Desktop started messing up when laptop users would boot without a internet connection present.  Also, since the web page was hosted on the company Intranet, a login dialog box would pop-up if IE was not configured properly which was confusing to some users.

Solution:

Rebuild the web page to not use Active Desktop, but still have the tools easily accessible.  Having a bookmark to the web page was not considered "easily accessible".

Result:

Fig. 1

Fig. 2

  Fig. 3

I decided to created a small application that runs in the system tray.  Right-clicking the icon in the tray would expand a menu of available tools.  Fig. 1 shows the menu and the employee search box that appears after clicking "People Finder".  Certain menu items are shown/hidden depending on the user’s login.  For example, my login shows 6 items, but "Support Ticket" and "Cams" are not show for others.  Rights are stored in the SQL database and not in the application so allowing access is simple and does not require an application update.  Since we are on the subject of databases…how should the application connect to it?  I decided to not connect directly to the database since the user would have to be on the network or have their VPN connected, but instead indirectly by using web services.  Using web services allowed the application to work as long as any Internet connection was present.  If a connection was not present, the application hides menu items that require a connection or certain rights.  I created a separate web site that hosted the web service application that basically would act as a proxy for my application.
Since I knew I would be updating the application as time went by, I wanted the application to be able to update itself.  I accomplished this by using some of the "Click Once" features of Visual Studio.  Instead of using the default settings, I handled the Click Once part programmatically so that I could force the update.
I added a "Sales Links" item that expands into a limitless list of links and sub-links.  The links can be  URLs, local folders, or anything that you can type into the Start>Run box!  Users with permission can easily modify and add links.  The application refreshes the links from the database every 30 minutes.
Lets talk security…
Since only a standard Internet connection is needed for the application to work, there were a couple of security concerns.  The web service application was open to the public!  That’s okay, lots of web service applications are open to the public…that’s kind of the point of them.  I decided to use "keys" that had to be passed each time the application consumed a web service.  In other words, a password (or key) is passed to the web service and every method (function) the web service has requires a password.  What about updates?  The application needs to look in a public place for updates.  If its public then everyone could download the program.  That’s okay too!  I just had to put some security measures in place with the application is launched.  Let’s just say that when the program starts it knows if it is suppose to be on that computer, if the check fails the application quits.

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.