Ken,
I am not a .net guy yet but one thing I / we all covet from .net is no dcom... The question is could a createobjectnet( class.object, machinename, flag) be used to call vfp.exe's on another machine using .net's remoting (or whatever the term is for createobjectex() is in .net) This would really help with n-tier applications even if it had some overhead (re: slowness) it might be acceptable) if hardware could solve it...
machine 1 VFP.exe calls createobjectnet()
machine 2 VFP.exe fires up and returns object or returnvalue or ado or xml to machine 1 (this would be awesome if this ever made it to VFP)
no dcom no problems
Probably not able to do this for dll's under MTS but if I didn't ask you couldn't say NO!!!!
jp
>>I think Ken eluded to some research that was being undertaken by the VFP team in this area in one of his newsletters/forum.
>
>I didn't mention it in a letter, but to individuals at conferences asking about .NET usage with VFP. We have a prototype of a utility allowing VFP to call .NET Framework classes without having to subclass or create COM objects from the .NET Framework classes. We are not ready to discuss or release any further details, it is just an experiment, and what I am asking from VFP developers is for them to tell me what .NET Framework classes they would want to be able to instantiate and use (and why) from within VFP without having to subclass and COM wrap them first.
User: "Can you make this small cosmetic change"
Programmer: "Just another total rewrite"