So, a wild goose chase... thanks for letting us know.

>Yes, when the server people made more cores available, the CPU load went down considerably.
>
>But the reason for the unexpected CPU load in general was something that I was doing in code. I was simulating a modal form, and I was repeatedly checking if the report window was still open. That worked ok when running on the PC CPU, but in a TS environment it was not good.
>
>After taking that out, the CPU behaved as I would expect; a little blip while the report was being created, and then went back to near 0 when the report was displayed.
>
>>>I got a call from a customer that said that Dell had identified my program as using 100% CPU while showing a Print Preview (in TS environ). I did not see it myself. So I checked on my machine. As soon as I ran the report, boom, CPU went to 30% or so. Dell identified my program as the process.
>>
>>If you have a 4-core machine, and your app in preview mode uses 100% of one core, that might explain what you see on your machine. Still not sure how they can get "100%" CPU utilization on the TS.
>>
>>You can add a check in your code for presence of (multi-session) TS by calling OS( 10 ), if it's present you can use SYS( 602, 0 ) to disable off-screen bitmaps and potentially improve performance on TSs.
>>
>>>Yes that is an interesting point about multiple core CPU.
>>
>>>It probably isn't FoxyPreviewer, as CraigB seems to indicate that it is VFP 9 itself.
>>
>>I'm not sure that's true. I haven't looked at non-FoxyPreviewer report preview CPU in REPORTBEHAVIOR 80 or 90 but you could use that as a baseline. If those are low CPU but FoxyPreviewer is not, maybe the latter uses some kind of event loop or polling. You could start another thread here asking about that, I seem to recall the dev/maintainer is easy to talk with and responsive.
>>
>>>>Still not 100% sure what you're saying:
>>>>
>>>>- are you seeing high(er) CPU utilization in both local and TS sessions, or just one or the other?
>>>>
>>>>- I'm surprised you'd see 100% utilization on a TS, they typically have lots of cores, a single session/process of VFP won't pin more than 1 of them so overall CPU usage should still be less
>>>>
>>>>- did you take a look at the processes tab of Task Manager to determine exactly which process is hogging CPU? Maybe it's something else like a real-time antivirus scanner
>>>>
>>>>If it does appear to be FoxyPreviewer you could contact them at http://foxypreviewer.codeplex.com/ .
>>>>
>>>>>Yes it came up in a situation when running in a Terminal Server environment; there CPU usage goes to near 100%.
>>>>>
>>>>>It doesn't seem to make any sense; the graphics have all been processed, and the report is just being displayed on the screen.
>>>>>
>>>>>
>>>>>>>I have a VFP 9 SP2 application. It was brought to my attention that when one of my reports sits at the print preview (I am using FoxyPreviewer, not sure if it applies to VFP reports in general) the CPU load is around 30%. This seems very high for sitting at a print preview. Is there anything that I can do to reduce this? When I am out of the print preview, the CPU load is less than 10%.
>>>>>>
>>>>>>First, use Task Manager to ensure it's your app that's using the CPU resources.
>>>>>>
>>>>>>Even if it is, my first reaction is "so what?". Typical modern PCs have so much free/available CPU that the end user won't notice the difference between 10% and 30% in use. And for a report preview it may not be for that long. Is it worth anyone's time trying to track this down?
>>>>>>
>>>>>>Having said that, one case where someone might legitimately care would be if the session running your app is virtualized (i.e. VDI) or is running on a Terminal Server. If the underlying hardware is being heavily utilized then yes, there could be concern about that extra CPU usage. But in a case like that you might need to be more concerned about bitmap settings in VFP - BITMAP=OFF in CONFIG.FPW or SYS( 602 ).