>Ever since Windows 3.0, if not before, the purpose of computers seems to be to click around and not, well, computing.
>
>As I'm frequently writing conversions from legacy databases, and these aren't trivial (or else they wouldn't have to be written), these tend to be long batch processes. Hands off. Nothing to click. No wait state, except for a wait window every 100 records, which doesn't count as activity - no wait state reported to Windows, so it thinks the app is stuck. I'm putting a DOEVENTS after every such wait window command, but alas, sometimes the Windows is faster and then it blanks out my app with that milky sheen, then the doevents kicks in a 20 seconds later, it repaints the window (looking at one now, it did so only first 65 times, now it's just all white, ignoring _screen.backcolor).
>
>Is there some API call by which I could tell Windows that I'm running a long batch and that it should ignore my process? As in "consider me irrelevant and stop checking whether I'm alive - I'm computing and can't answer your tap on the shoulder every minute".
>
>I do have other means of tracking - in cases like this I also save a log entry every 100 records (which is ugly and makes the log crowded with unimportant information) and then can look at it from Total Commander's Lister (simply press F2, it refreshes so you see the latest lines). But that's ridiculous, I'd rather have my code show something by itself and have Windows NOT hiding it from me.

ISTR tactical DOEVENTS calls working for me in long-running batch processes, coupled with the right setting of .AutoYield (can't remember if it had to be .T. or .F., I suspect .T.).

Update: Paul brings up a couple of good points:

- If your processing is heavy SQL queries, I know of nothing easy you can do to get around that. As he suggests a separate thread is probably the cleanest way to go. One way to do that is to farm the processing out to a separate COM EXE

Some time ago I did some evil speculation about issuing DOEVENTS in a UDF within a SQL query e.g.

SELECT ;
  YourCols ;
  , SomeUDF( SomeUsefulValue ) AS DummyCol ;
FROM ...

FUNCTION SomeUDF ( SomeParam AS SomeType) AS Logical

* Call DOEVENTS selectively rather than with every UDF call
* Or just call DOEVENTS and forget about the passed parameter
IF SomeOtherFunc( SomeParam )
  DOEVENTS

ENDIF

RETURN .T.

ENDFUNC

I never tested this so I don't know if it works or what the performance hit might be. I also wonder if this concept could be used to update a progress bar during a SQL query (in place of the built-in one).