>Would not have guessed that the COM Array marshalled from .NET Char[] has numbers in each Item needing a CHR() if accessed from vfp - but COM and Arrays often were/are terra incognita for me...

Char is not supported over COM. Neither is byte (byte array is an exception).

The COM Array parsing is my doing actually - I basically convert any unsupported types as well as arrays. What would you expect that to return? An array of strings?

I have to take a look at and see what natively comes back. wwDotnetBridge's fixups for sure slow down the processing as well as I have to check for all sorts of special types (value types, special handling for byte arrays, generics, some of the base types like Long etc.) - lots of stuff just doesn't work natively over COM. It's a tradeoff I'm aware of but I figure reliability is more important than raw speed - if raw speed is needed creation wrappers in .NET and directly calling the methods without the intrinsic calls is the way to go.

In this case of the character array or indexable interface - I'm not sure what could be returned that works. Some array types can actually be passed into FoxPro directly and accessed as arrays, but the rules for this are weird and I can never remember what exactly works and what doesn't, plus you can't update the arrays passed as they're basically passed by value.


Anyway - it looks for this scenario either Marco's approach of chunking the string (preferrable to me) or Christoph's using native memory allocation solve this problem without having to go through interop and both produce a roughly 10x gain over the .NET/COM version.

OTOH, as I mentioned even adding in some code to increment a counter ended up doubling the request times, so if inside of the loop a bunch of other code runs, I think the overhead of the parsing gets minimized a bit.


+++ Rick ---