>>>>How about setting the datapath in an application registry entry? Using the Registry class in the FFC, or any one of several registry classes found here in the files section, it would take only two lines of code.
>>>
>>>How does the component know which application it is currently working for and registerd to in that case? Just to add some more detail: I have an object that gets used by several applications. One second it could be instantiated doing work for WEBFAX and ConForm the next, both having different data paths.
>>
>>Ahhh, ok. I misunderstood. You can get a context object which will give you a reference to the IIS objects from inside your component. from there, you can fetch the application's path from the Server object like you did above. I posted some code just yesterday that shows how to do this, and suggests a class mechanism that will make it easy. check out Message #354497. Let me know if you have questions.
>
>Worked like a charm...I actually skimmed that message yesterday and had no idea what the code was doing, I guess I should have actually read it. This should make life much easier. I'm very interested in some more detail regarding the ASP/MTS Object class you described in message#354497. Where is the best place to get the neccessary information to get me started??
>

The context object is actually provided by MTS, but works even when the server is not running in a package.

Randy Brown wrote a decent article on MTS and VFP on the VFP website at http://msdn.microsoft.com/vfoxpro/technical/articles/comactivex.asp. This article talks some about context, and briefly mentions that the IIS objects are available through the contextobject, but doesn't give any examples regarding this.

As far as my suggestion for implementing this on a class level, just do this: create a custom class that you will use for all classes directly instanciated by IIS. In the class, add 3 (or more) properties: one to reference each the Request, Response, Server objects, and if you want, the Session, and Application objects. Create a method GetIISObjects() that will create the object context with the code I posted earilier, and then assign a reference to each of the IIS objects to your class properties:

THIS.Server = oCTX.Item("Server")
THIS.Response = oCTX.Item("Response")
THIS.Request = oCTX.Item("Request")
THIS.Session = oCTX.Item("Session")

Then from every method that is called from your ASP, first call the GetIISObjects method, and you will have a reference to each IIS object. Why not call this method from your class' Init? Well you probably could. But if you are programming statelessly, remember that the actual object doing the work in each method call might not be the same object you instanciated, so your context reference will be hosed. Currently, the IIS pool manager destroys and recreates the object on each method call, but I expect that soon, the objects will live in a real pool, and we will not even be able to count on the Init method running every time your object is "created".

If you are programming statelessly, and running your objects in MTS, it would also be a good idea to have your object wrap calls to MTS' SetAbort and SetComplete, and actually call them only if the context object is not .NULL.. You can also wrap your Response.Write method to have it return output to the screen if the object is not being called from MTS. This way you can still test your objects from the command window.