People often rely on String to binary data type coercion, but it can fall down (hard) in many scenarios.
There is always the cross-locale issue with many data types (Booleans, numbers, and date/time in particular). Then there are custom values e.g. Yes/No.
I'd hoped that this ParseTypes class, awkward as it is, would help parse and convert string text into strongly typed data. ParseTypes is based on the StdDataFormat object used by data binding.
I can't find the interfaces of this object that get used by data binding sources and sinks. In any case they don't seem to be exposed by the typelib of MSSTDFMT.DLL at all.
So as an aid to experimenting with this I am using a one-row fabricated ADO Recordset with DataFormat properties set on its fields. One field for each data type. Then I create a clone of this Recordset without DataFormat objects so I can get the strongly typed data out.
Ideally if this was going to be useful we'd find a way to work with StdDataFormat objects more directly and omit the use of these Recordsets. However after testing this doesn't seem anywhere near as useful as I had originally hoped anyway. :mad:
See the screen shot:
Some of these are using Format strings, others are using additional StdDataFormat properties.
Case 4 might appear to be working but it isn't. The Format gets ignored and default CDate() conversion gets used instead, yielding an incorrect value. Case 5 addresses this by using the UnFormat event and "manual" code to perform the parsing and conversion.
Cases 6 to 8 are also flawed and are working only because those are the default CCur() conversions. The Format strings do not get used.
Caes 9 and 10 are a little weird, but working as desired. See Form1's code to see how ParseTypes1 was set up for TypeName = "String" data.
So while this isn't complete (as in completely working) it still works for some cases, so I'm posting it here as sample code. Hopefully somebody will be able to point out improvements... or ideally some other library that can do this very thing in a lighter manner with broader case coverage (for example actually parsing date/time string values according to a format string).
Dealing with date/time parsing in the UnFormat event works, but at that point you may as well skip all of this plumbing and just write a simpler date/time parsing function with the same logic in it. My hope was that even if relatively low-performance StdDataFormat would make it easy to change formats simply by changing the Format string instead of rewriting parsing code. Oh well!
I'm not sure where the "magic" happens here, at least the magic of the working cases. This seems to be mostly within MSSTDFMT.DLL even though the documentation for StdDataFormat suggests this is done by "the database" (which probably means by ADO or DAO depending on the case).
There is always the cross-locale issue with many data types (Booleans, numbers, and date/time in particular). Then there are custom values e.g. Yes/No.
I'd hoped that this ParseTypes class, awkward as it is, would help parse and convert string text into strongly typed data. ParseTypes is based on the StdDataFormat object used by data binding.
I can't find the interfaces of this object that get used by data binding sources and sinks. In any case they don't seem to be exposed by the typelib of MSSTDFMT.DLL at all.
So as an aid to experimenting with this I am using a one-row fabricated ADO Recordset with DataFormat properties set on its fields. One field for each data type. Then I create a clone of this Recordset without DataFormat objects so I can get the strongly typed data out.
Ideally if this was going to be useful we'd find a way to work with StdDataFormat objects more directly and omit the use of these Recordsets. However after testing this doesn't seem anywhere near as useful as I had originally hoped anyway. :mad:
See the screen shot:
Image may be NSFW.
Clik here to view.
Clik here to view.
Some of these are using Format strings, others are using additional StdDataFormat properties.
Case 4 might appear to be working but it isn't. The Format gets ignored and default CDate() conversion gets used instead, yielding an incorrect value. Case 5 addresses this by using the UnFormat event and "manual" code to perform the parsing and conversion.
Cases 6 to 8 are also flawed and are working only because those are the default CCur() conversions. The Format strings do not get used.
Caes 9 and 10 are a little weird, but working as desired. See Form1's code to see how ParseTypes1 was set up for TypeName = "String" data.
So while this isn't complete (as in completely working) it still works for some cases, so I'm posting it here as sample code. Hopefully somebody will be able to point out improvements... or ideally some other library that can do this very thing in a lighter manner with broader case coverage (for example actually parsing date/time string values according to a format string).
Dealing with date/time parsing in the UnFormat event works, but at that point you may as well skip all of this plumbing and just write a simpler date/time parsing function with the same logic in it. My hope was that even if relatively low-performance StdDataFormat would make it easy to change formats simply by changing the Format string instead of rewriting parsing code. Oh well!
I'm not sure where the "magic" happens here, at least the magic of the working cases. This seems to be mostly within MSSTDFMT.DLL even though the documentation for StdDataFormat suggests this is done by "the database" (which probably means by ADO or DAO depending on the case).