>Hi all,
>
>Im pretty sure that I know the answer to this, but I thought I'd try it out on the group < g >.
>
>Im translating some Delphi code to VFP. The code calls out to the EnumWindows API function and passes a pointer to a Delphi function to be used as a callback function.
>
>This cannot be done under VFP can it?
>

Not without a .DLL or in-process ActiveX control which will return a pointer to one of its interfaces, which you could supply for the callback. I believe that Christof mentioned some possible support for hooking the Windows message entrypoint as a future enhancement for his STRUCT class, so check that; I normally just have a wrapper for the API calls that require a callback (I write it in C++; you could create a C-style .DLL with Delphi as well, or generally any programming language which can produce standard C-style DLL interface .DLLs and will provide the address of internal routines when services from the app should respond to requests for action, letting your app deal with results prior to returning from the API call, or notifying some part of your app of some event or change in state that it wants to respond to even after the API call completes.

Writing a .DLL to publish a callback address is not difficult in C++ or Delphi; both can produce a standard C-style DLL entrypoint which VFP can get at with DECLARE...DLL, and some other entrypoint in the .DLL may be used from the DLL code as a callback. VFP doesn't offer easy access to regular VFP code straight from a callback, but will (eventually) see and react to getting normal Windows messages, like someone hitting a key. Our entrypoint which was given as the callback would record any relevant details from the callback, and then use the Win32 API to synthesize a Windows message which VFP would see as a keystroke. Gee, I can't think of any VFP function that would call some routine when it got a specific keystroke, can you? < g,d&rvvf >

Obviously, given VFP's propensity to stop responding promptly when running some non-interactive and resourse-draining routines - the places where people are faced with Task Manager reporting that VFP is Not Responding will recognize this sort ofproblem - VFP crunches away at something which is memory and data-intensive, and stops checking for UI events while this line of code or processor-intensive, tight section of code that runs fully in-line, without calling a UDF or method, eats every bit of the time given for it by the OS, bufering the UI events received (including timer events) until it either calls some other function or method, or doesn't think that finishing this routine is the absolute, exclusive and necessary activity for it to run - after all, you, the Grand Wazoo, would give it a sign saying "Look to see if there's something more important waiting for your efforts" by telling it:

(1) to check for UI events by calling DOEVENTS()
(2) change it's current scope of reference by calling other procedures, UDFs or methods
(3) responding to some runtime error processed by VFP (errors which force Windows to protect itself or another process from VFP's misbehavior result in the VFP app getting shut down instantly - VFP never gets a chance to report it, since once the VFP process tries to do something illegal, it becomes untrusted, and Windows refuses to let it get a second chance.)

>The callback function checks for a specific window title, so Im sure that I can use the FindWindow API function just as easily or George Tasker's Is_Run.prg, but I just thought I'd ask.
>

The behavior is not identical; if spawning NotePad from your VFP app using RUN (or ShellExecute() as long as you know that NOTEPAD gets called for the file extension used) you may want to look at API_APPRUN, which can run, track, wait on termination of, or force unconditional shutdown of both WinApps and DOSApps from inside your VFP app. It implements CreateProcess() to execute standard applications (this can include .BAT, .CMD, and various WSH-compatible scripts if they are offered through through the WSH) and offers some control over the ShowWindow mode when the program starts up. It does not create a DOS console Window unless required for the app. You can retrieve a termination code from the app once the process finishes.

Currently, I'm testing an updated version; it should provide:

(1) Control of Window and Console sizes and screen positions
(2) Control of starting Win16 apps in their own VM (NT/Win2K only)
(3) Ability to create an alternate environment
(4) Ability to direct STDIN/STDOUT/STDERR to currently opened file handles
(5) Ability to get Main hWnd and issues Windows message via SendMessage() or PostMessage() (WinApps only)
(6) Setting process priority (no support of real-time priorities)

Setting up PIF files for DOS Apps to force Close After Shutdown is a goal, but currently isn't probable.

The class will be released in a PD version implementing present services and items 1 and 2 by Sept 1 of this year.