>>I try to avoid parameters, relying on properties that can be populated before invoking a method - it makes things easy if you find yourself having to pass the same value around as a parameter. It also simplifies deployment considerably; passing parameters by reference to an out-of-process server, especially a remote out-of-process server, may be unpredictable, and if you use the OLE interface, translation between data representations in different languages is handled neatly and automatically.
>
>How so?
>
>Also, keep in mind that a COM property assignment is just a method call
>anyway, so you're not saving yourself anything by doing so. In fact,
>if you're worried about remote components, you want to try to pass as
>many things in a single method call as possible to avoid the remote
>protocol overhead incurred by roundtrips.
>

I've run into all sorts of problems where I've needed to pass an array of char with embedded nulls to a VFP COM object; if I stick an array of char into a property, I don't run into the same problems I have when passing the array of char as a parameter. I don't know why I have the problem, but it's bitten me a couple of times in an object that I use for one of my routing servers. If I could reliably pass an array of char to VFP by reference and get it back resized, I'd be a much happier camper - what I do now is pass in the list of known intermedite points, and then read a property on return to get the adjusted route.

Yes, I am aware that an assignment is a method call that actually invokes the necessary marshalling needed to pass stuff across a process (or even at times across a thread) boundary. Maybe I'm doing something dumb.

Ed