Win32 API - CopyFileEx method

[skiflirt]

Has anyone succesfully used the CopyFileEx method from within VFP5 or higher?

 

[DSummZZZ]

No, but I have used CopyFile:

DECLARE INTEGER CopyFile IN kernel32;
STRING SourceFile,;
STRING TargetFile,;
INTEGER ExistsCode

? CopyFile ("C:\test.txt", "C:\test.new", 0)

Dave S.

 

[skiflirt]

Hi Dave,

Thanks for the reply. I've used CopyFile myself. I am trying to use the CopyFileEx method to give feedback on the progress of a copy. It contains a CopyProgressRoutine as one of the parameters and that is what I am trying to figure out.

Thanks!

Bruce

 

[rgbean]

Bruce,
That parameter is a pointer to a CallBack routine. This is one thing you just can't implement directly in VFP, due to VFP's dynamic interpretive nature. One techique to do this, would be to create a Visual Basic control to handle it, and then use this control on your form. Also, it's apparently &quot;trivial&quot; to implement IF you know C++ and you create your own .FLL <g>.

Rick

 

[skiflirt]

Well isn't that just peachy! I guess that leaves me out as my C++ are really C--.

Know of anyone that has done this before?

Bruce

 

[rgbean]

Bruce,
I'll quote from a man much wiser than I - I got this from the UT (

http://www.universalthread.com/):

&quot;Actually, if you're willing to put in a tiny bit of effort, callbacks are doable writing a small piece of code in another language. The first and oldest of these mechanisms is to create an FLL in C++ using the VFP API; the FLL would need to publish an entrypoint in itself for each type of callback; you'd get the address of the proper entrypoint from the .FLL as an integer, and then pass that as an integer to the API function. The .FLL would receive the callback, and could then populate VFP memory variables or fields in a cursor; an FLL can directly manipulate the VFP runtime environment. Christof Lange published the VC++ source of an FLL to do just this around 3-4 years ago. It requires working in C++, but most of the work is already done. Obviously, the FLL needs to ship with the app.

The same type of thing could be done with an ActiveX component; the ActiveX component would publish an entrypoint, and populate a collection with results, and can surface an event that VFP could respond to. Again, it involves working in another language like C++ or VB (Dan Appleman's first Win32 API book for VB included sample source code forworking with several types of callbacks), and the component would have to be registered on each target system.

You'll find that the need for callbacks will lessen as the Windows environment evolves - many enumerations can be accomplished using the WMI, and we'll be able to access .NET resources via an Interop layer at worst in the VS.NET release of VFP, and in all likelihood, VFP6 will have some capability to use Interop-wrapped .NET services via COM. We'll know more when the VS.NET beta actually ships. In the meanwhile, you can simply use tools other than VFP to manage C-style DLLs requiring a callback, and expose the services and results through one of the many existing interfacing options like FLLs, C DLLs or COM.
EMail: EdR@edrauh.com
&quot;See, the sun is going down...&quot;
&quot;No, the horizon is moving up!&quot;
- Firesign Theater

&quot;