A nice easy way to patrol and eliminate orphaned processes 

I have several web applications on our local intranet that require Excel to be called to make documents for my users.  That brings up a problem:If you add the impatient tendancies of users (hey, I just clicked that button, I want my spreadsheet NOW!) to the statelessness of html on top of the stubornnessof the Excel process you get orphans, those pesky orphans that sit around, use your resources and do nothing.  Now programatically, I have done all I can to kill these bastards but I can't seem to stop the persistant jerks 100% of the time.

So, what I decided to do was to make an 'enforcer' on the web server that makes his rounds every five minutes and kills any of these little pricks that are still hanging out in my otherwise peaceful system.  This enforcer is not only effective, he is also efficient (tiny script, executes instantly) and keeps track of his work (log file).

The code for my vbs file can be seen here:

As you can see, it's very simple, and you can change it to eliminate any kind of process you want.  Here it is if you want to check it out, included is an empty log file, the vbs file, and the bat file used to schedule it (assuming you place this in c:\scripts\), enjoy.

An annoying little 'feature' of Excel is that it stores dates in a strange format

I stole the logic and from Code Project and wrote some code that will give you a DateTime variable if you feed it a Excel serial integer (number of days after 2/29/1900).  Strangely enough, DateTime.Parse("2/29/1900"); throws an error, so the simple solution I thought of: DateTime.Parse("2/29/1900").AddDays(excelInteger); does not work.  But this does:

As long as your date isn't within 60 days of 2/29/1900, this will work perfectly (don't ask why those are screwed up ).

Have your users make spreadsheets online, no excel needed

Now first off, this places a DataTable into the Session State, and I know some people have a problem with that... I don't care.  Now that that is out of the way, I can explain how this works.

It is very simple, this program runs through all of the TextBoxes and DropDownLists that you have within the input_container Panel and adds them as string columns to a DataTable dt.  Once that is done, each entry is simply added to the DataTable and rendered onto a GridView.  Then I use Matt Berseth's GridViewExportUtil to spit the spreadsheet out to the user.  Everything is taken care of real-time with no writing to the disk. Pretty simple.

I also included a way to edit as a normal method wouldn't work in this case, it just populates a DropDownList every time you add a new item and pops it back into the forms if you choose to edit it _but_ if you do not save, the record will be lost (there is a warning).

Another thing to note is that this is a drop-in-and-use application.  Everything is populated automatically, you need to do absolutely nothing to the code-behind in order to use this utility, just customize your fields in the default.aspx in the input_container and the rest of the work is done for you.  I used my method of parsing IDs of the input fields to make column names so ddlLets_Party turns in to a column "Lets Party", Last_Name becomes "Last Name", strFruit becomes "Fruit" and so on.   You could easily add another attribute as ColumnName or something like that if you please.

Here is the provided example: Excel Spreadsheet Builder In Action, and the code:

This can be done via a web-interface via Excel Interop commands

I was asked to take some user input, produce an Excel spreadsheet, then append it to an exisiting workbook that had multiple static spreadsheets then spit the Excel sheet out as a download.  Excel Interop processes are not that easy to work with, and can be quite a pain.  After fumbling around, I was able to come up with a (possibly rudimentary) way to do this.

Now this is just a small part of a much larger program that takes in user input, and saves it to a temporary directory as an Excel spreadsheet.  Inside that directory there is also another file that doesn't change that thsi will be appended to, I call this my 'base' file.  The snippet I am providing combines the files and saves them as a seperate new file before my program sends it to the user.

There is likely a better way to do this without all of the saving with a stream, but I am not sure how and am wide open for better solutions!  Anyways, here is the function I ended up using.  The inputs are:

• baseFile is the path to the static file I am appending to
• newSheet is the path to the new file that I am appending to the base
• newFile is the path to the final appended sheet