ObjectListView and Filtering Dates???

david.wendelken posted on Wednesday, January 02, 2008

Per Rocky's advice, my business objects have public string properties for EffDate and ObsDate (EffectiveDate and ObsoleteDate) although the private variables are SmartDates.

I'm trying to filter on these values using ObjectListView and having a bit of trouble.

My Filter expression is:

EffDate >= #1/1/2002# AND EffDate <= #12/31/2004#

I get this error message:

Cannot perform '>=' operation on System.String and System.DateTime.

How are other folks handling this? I'm looking for best practice here. :)

david.wendelken replied on Wednesday, January 02, 2008

Now I'm having a problem when the date is null (which means the string representation = String.Empty).

As soon as the filter runs into an empty date it barfs with this message:

An exception of type 'System.FormatException' occurred in mscorlib.dll but was not handled in user code

Additional information: String was not recognized as a valid DateTime.

I'll just mention that the programmer responsible for that message in DataView should have supplied the offending value as part of the error message... :(

I've tried testing for null, but it doesn't seem to short-circuit the exception processing to do so. :(

Here's my expression:

IIF(ISNULL(OBSDATE,'Y') = 'Y',#01/01/1901#,CONVERT(ObsDate,System.DateTime)) >= #" + filterObsDtSt + "#"

filterObsDtSt has a value of "1/1/1901"

ObsDate has a value of "".

Any ideas?

tmg4340 replied on Wednesday, January 02, 2008

I don't want to be the guy to go against Rocky's advice - especially with his own framework! - but why are you working with your dates as strings? Why not just use the DateTime value? Then your empty date will either be DateTime.MinValue or DateTime.MaxValue, which you should be able to work with without all the string futzing.

- Scott

JoeFallon1 replied on Wednesday, January 02, 2008

The old IIF function evaluates both parts! It will always crash. It does not do what you think it does.

I believe a new IIF function was added in VB9 that should do what you want. You are better off writing the 3 lines of code to do it the right way anyway.

You can expose your properties as Dates too. Sometimes you want to display the string for binding but sort on the real underlying date.

Joe

david.wendelken replied on Wednesday, January 02, 2008

There are several reasons I'm exposing my date properties as strings instead of SmartDates or DateTimes.

Reasons against using DateTime:

Does not support null dates.
I hate to show bogus dates to a user because of the above limitation. It's unprofessional in appearance. Telling a user that "January 1, 1753" really means "I don't know" is dorky.
In a list of records, most of which will have null dates, bogus dates "visually hide" the known dates. When unknown dates are shown as blank values, the known dates are very visible in the list.

Reasons against SmartDate:

ReadOnly classes: none.
Editable classes: You can't assign a new Text property to a SmartDate property. You have to create a new SmartDate variable and assign it to the SmartDate property. (Oddly enough, you can assign a new Text property to a SmartDate variable, however.) The extra object instantiation is slower, requires more code to be written, and is less intuitive.

Reasons against String:

Built-in capabilities don't know the "real" datatype underlying the property.
For the same reason, this makes writing generic code that properly responds to the property's datatype harder to do. It also makes writing code generators that work off the object harder to do because you have to supply the metadata about the datatype somewhere else.

So far, to me, it's seemed like a Monty Hall gameshow where all three doors had glasses of hemlock as the prize. :(

david.wendelken replied on Thursday, January 03, 2008

I finally got it to work. Had to turn the IIF and CONVERT functions inside out. Here's the first part of the test:

CONVERT(IIF(LEN(ObsDate) = 0,'01/01/1901',ObsDate),'System.DateTime') >= #" + filterObsDtSt + "#"

Brian Criswell replied on Thursday, January 03, 2008

The ObjectListView implementation has a supporting interface and event that come with it. IExtendSort and ExtendSortEventArgs are used by the ObjectListView to decide how to override the default values for sorting. The primary purpose for this is dates exposed as strings. Your object in the list can implement the interface and replace the value that would be used to determine sorting with another value. So, the interface's method body would see that you are trying to sort by the date value which is normally exposed as a string. Instead the method would return the SmartDate.Date value, which automatically puts null dates as the max or min date for sorting purposes. The event args are used when you cannot modify the object directly or want different custom behavior for a particular sort.

I know this does not solve all of the problems with exposing strings, but it does help the sorting issue.