I disagree; in the interest of keeping the plugin small, to do this outside the class is equally minimal effort and I don't think the plugin should accept every possible representation. If you always use Date where String is required, you can overload and wrap the function to perform the conversion.
Kelvin: That said I think that given it's a *date*Picker, Date would be a far more appropriate choice for the interface than String. What made you choose String? --rob On 6/6/07, Brian Miller <[EMAIL PROTECTED]> wrote:
Just my opinion: both Date and String should be supported. It's probably only two lines of code to check for type, and cast to the other type if necessary. - Brian >>> There's a bug or documentation error with dpSetSelected() [revision >>> #1993] : it's documented as taking a string, but the code for it >>> requires a Date (due to using .getMonth(), .getFullYear() and >>> .getTime()). >>> >>> To fix this problem I added the line d = new Date(d); to the start >>> of dpSetSelected(). >> >> It's a documentation error. I'll update the documentation to explain >> that it expects a Date object (the change you made might have other >> unforseen consequences). >> > > Hi, > > Just an update on this... I've decided that the documentation was > correct and so I've changed the function to behave as it described. > dpSetSelected now expects a String as documented. I also fixed the other > documentation errors you noticed, > > Sorry for any confusion and thanks for the report, > > Kelvin :)
-- Rob Desbois Eml: [EMAIL PROTECTED] Tel: 01452 760631 Mob: 07946 705987 "There's a whale there's a whale there's a whale fish" he cried, and the whale was in full view. ...Then ooh welcome. Ahhh. Ooh mug welcome.
