Hiya Jim:

>
>I read this massive book regarding COM, and one of the things that "stuck" was the (alleged) "standard" to always have a version number (or something quite similar) in the "registry", thereby (allegedly) allowing multiple versions of the same object to exist in the same system.
>

Actually, you're not supposed to have multiple versions of the COM object: You're supposed to add "interfaces" to existing objects. For example, you may support "oCOMServer.GetValue("Name")" and then, later, add "oCOMServer.GetValue2("Name")" ... one of the -NEVERS- of COM theory is to change or delete existing interfaces....which is not really realistic.

>The theory was along the lines of older apps would know and recognize and look for the older "version" while newer ones could use the newer one. There was even some bit to say if the new *could* be treated as an 'old' or not.
>

>But, as we have seen, even MS does *not* (seem) to adhere to this - witness troubles epople have with incompatible versions of treeview or mscomm or whatever!
>

Yeah.....remarkable the distance between theory and implementation, huh?

>A comment on "data-driven. . . so I'm contracted to work on this "table-driven" system. Should be interesting, I thought. But there, throughout the code, were hard-coded all manner of distinct values. Yes, stuff was in tables BUT *not* the 'meaning' of the stuff. That was left in the program!
>

That was what I was trying to point out in my original response: The fact that -logic- and, maybe some values, should be left in code but in a separate business class and that time-sensitive values could be put into a table.