>>>>>>It really depends on what the process should do. Personally I used this solution for reporting, sending emails and a few other tasks. The users were really happy to start a report, and be able to continue with their work straight away. As soon as the report finished, it arrived by email.
>>>>>>
>>>>>>If you can give more info, I can see if I can give you some more ideas.
>>>>>
>>>>>Basically it connects to SQL Server, runs a query, if anything is found it formats the data and creates a table in the temp folder.
>>>>
>>>>So the time consuming part is the query itself?
>>>
>>>Yes around 90%. I could not make it async for some reason, it is a query that executes over multiple databases.
>>
>>Would it be a solution to simply pop a messagebox or something when the query is finished?
>
>The thing is, 99% of the time the query will not find anything. So it continues running on the background, perhaps every minute or so, and if it finds something, it should show the result in the main application. But the main application cannot be in any way affected. I cannot install anything like a service at the client, so it must be handled from the main application. I am now working on the first strategy, with starting the exe once at startup, and waiting for the instruction file, and then runs the query. The Exit.xml will then kill the process. (This I can later improve by using a file lock).

Unfortunately I'm out of ideas. All I can think of, is the sample that ships with VFP9. Starts the Samples application, check New in VFP9 ->Binding to Windows Message Events. In the dropdown, check File/Folder Shell Events. Binding to these events will take a minimum of resources, so I doubt that it will interfere with the normal operation of your application. Actually, I have seen this live in a big application, but I don't remember any details.