>>Er - you're not going to inline a commercial library. And even if you 'just' call it you still have to deal with memory management buffer overruns and all sorts of other security issues that make it very easy to do damage.

People allocated memory via VFP strings for years to use the likes of GetPrivateProfileString without disaster. You can do the same with inlining and let VFP clean up the variable when you're done. As for security- why would inlined C++ be less secure than a separate dll that is laughably easy to hook? I can hook the 7z dll in less than a minute and scoop the password as soon as it's used, but it's far more difficult to undetectably pick apart a bespoke dll with no convenient entry points.

>>But whatever floats your boat - if you're into that sort of pain by all means - somebody's gotta do it :-) I've done my share of C++ over the years and I'd be happy if I NEVER have to look at it ever again.

Pain? The only pain I see is for the wannabe hacker. ;-) At design time it's very easy, since Chan has changed #insert so you can insert your C++ file as one line in your prg, preceded by your VFP variable declaration to allocate memory if that's not part of the C++.