On Behalf Of Hajo Kirchhoff
Brian Braatz wrote:
you split the lib into a few pieces:
1- Get the data from the data base and stream it into X 2- a stock form of "X" (like the table you described) 3- Helpers for binding
if you built the thing that way, then it will be usable by those of us out there who have large bodies of code relying on things like ADO recordsets. I would love to replace the recordsets, but I need to be able to selectively use pieces of your library and I need to have a usage model that is similar.
Thanks, interesting thoughts.
Hajo
[Brian Braatz Writes:] If you are interested in collaborating, I have wanted to (for some time now) build the table<> aspect of what you are working on. My goals: 1- functional drop in replacement for ADO recordset 2- Dynamic and static "views" and indexes 3- binding model that does NOT force you to use the bindings supplied with the library this is something ADO lacks, and something I have had to work around to great frustration 4- the ability to COPY from one table<> to another table<> * ADO does NOT ALLOW you to copy recordsets. (brilliant no?) Additionally - I am not sure if he is still interested, but Joaquin Munez and I exchanged emails awhile back about collaborating on such a beast. The general idea was to take the functionality in multi-index container and make it work dynamically. (and there is more) I am working on something unrelated to this discussion that could form a good foundation for table<>. I should have something to share middle of next week. Just let me know if you are interested in putting our heads together. :) Brian