new toolbox function

Probably of more interest than my last post: I added a function to the toolbox that will take a datatable, and email it as an excel attachment. Exciting!

new validation function: isValidPassword

I added a new function to the toolbox to validate a password field specifically, assuming that the password may have upper/lower case letters, numbers, or any one of a few punctuations (see actual code for reference). I'm posting about this because I added it to the ValidateAlpha class.As I did so I thought that really the Alpha is not the most accurate name as there are functions in there that validate strings beyond just alpha. However it's kind of late to rename it since it's widely called.

Just be aware that these kinds of functions may already exist before troubling yourself writing a new one!

running ie 6, 7 and 8

just read this - for the curious:

http://blog.case.edu/jeremy.smith/2008/03/07/ie_6_7_and_8_running_on_same_machine

I'll be trying it fairly soon, because I still like to test in 6, but I guess some goobers are using 8 now!

referring to radio button in DOM fashion

so for ages now we've been calling a radio button using the non-DOM method of document.formname.radiobuttonname. But yay! Recently Jason & I figured out the DOM method for doing it: document.getElementsByName("radiobuttonname")[index]

Remember these are 0 indexed.

So feel free to change your javascript to it's entirely using the DOM way to reference page elements. Exciting stuff!

share a user control across projects in a solution

I used this article to figure this out. Here is my summary of the article, for what I did for a recent solution.

You can keep the user controls to the project you initially created them in, but use then in other projects of the same solution by adding a pre-build event to the project where you want to also use the controls. You can add such an event by going to the Properties of the project (right click on the project in solution explorer) where you want to add the controls, and go to the Build Events tab. You type a command to copy the controls from the project they were created in, to the project you want them to be used in. Then, before running a build on this project, if you have directed the control to be copied into a directory, you do need to make sure that directory exists. For DOM at this point, I created a folder called UserControls into whatever project I was adding the controls to. Finally, after you run the build, make sure you include the folder and/or the controls that were just copied over in the project they were just copied into.

export data into excel

Sigh...the eternal struggle. As you may know, we have some code, a couple versions actually, of a function that takes a gridview from a webpage and exports it into Excel. 2 problems: 1) sometimes it would break if the gridview used .NET controls it hadn't already been written to handle, and 2) what got put into excel was really an HTML table. Thus if someone tried to import it into certain statistical programs for analysis it might not be correctly read as real data. Not ideal!

A couple months ago, Dave found an article about putting a dataset into excel - nice! You don't even need to make a gridview on a webpage, you could create a dataset and send it straight into an excel file. I spent some time this weekend adding it to the toolbox, and making a version that would work with a datatable*. Then I read about a possible issue - what it is exporting into excel is XML formatted data. This could be a problem, not all statistical software our clients use will be able to import XML is my concern.

A little more research and I found an article by someone who explained how to send data into excel without a gridview, and it's not XML formatted. It essentially sends a tab-delimited, plain text translation of the datatable. I created another class based on this method. I ran into one very odd bug - a Microsoft bug, natch - that if the first column is called 'ID' in caps, it break. No comment. 

Please note that in the case of the both the XML formatted data and the plain data exports, since the gridview is not used, the data in Excel is exactly what is in the dataset/datatable. Therefore, if you have a gridview that formats the phone number for display purposes, but you use one of these classes to export the same data that binds the gridview, the end user will see the un-formatted data.

In conclusion, I plan to implement the plain text to Excel version from now on. It is in the Toolbox under DCReports, called ExportData.cs. The version that creates XML data from your data, then exports, is called Workbook Engine. I added the original sample code, and a version that handles datatables.

Questions? Comments? I long to hear the feedback!  ;)

Helper Functions for gridview

I added a class for helper funtions to format gridview output, that can be called from the gridview in the aspx page like so:

Amount:
< % # DCToolbox.DCReports.GridviewHelpers.FormatShort(Eval("grantStartDate")) %>

FormatShort, for example, takes the object and if it's not a dbnull then it converts it to a short and displays that value, as long as the short is not one of the missing value constants for short in the DCConstants class.

There are only a couple of functions in there so far, please feel free to add more. I didn't find anything like this in the toolbox, but I didn't look hard so please let me know if it's redundant.