Liveware Publishing Support Forum

When I print a report to the screen and leave it open for viewing I notice the task manager indicates I am using 100% of my CPU clock cycles to keep this window open.____This seems excessive use of computer resources.____Is my assessment accurate and if so, is there a fix for this coming in the near future?____Thx.__Ken

This bug is listing on our FAQ page as follows:____Q) When I preview a report in either R&R or Arpeggio, I see 100% utilization of my CPU. Why is this happening? ____A) This problem is caused by a behavior in the software where a processing loop during preview is consuming all available CPU cycles. Processing large amounts of data is by nature a cycle-intensive process and even during print preview, R&R is deriving totals for display and dynamic updating. __In most environments, this issue will not impact users to any noticeable extent. However if users are running under NT Terminal Server and any Report Writer user is previewing a report, performance will degrade for all other users and applications on that Terminal Server. Until we are able to address this problem, the suggested workaround is to limit the use of print preview to active viewing of reports rather than allowing an unattended print preview window to remain open. Printing and exporting of a report do not exhibit the problem and may be a better alternative to preview in a Terminal Server environment. ______Kathleen__R&R Support__

>A) This problem is caused by a behavior in the software where a__> processing loop during preview is consuming all available__> CPU cycles. Processing large amounts of data is by nature a__> cycle-intensive process and even during print preview, R&R is__> deriving totals for display and dynamic updating____Not really exact: Logically - it would be 100%CPU usage for the time, in which RRWRUN calculates. But in this case not.__if you leave RRWRUN.EXE in preview for 1 hour, it will still be__100% CPU.____Most obvious, RRWRUN.EXE has an event loop, which waits for mouse__and keyboard events and does not leave system it^s time slice back to OS.____And in my opinion - it^s a remnant of 16 bit days, when such behaviour for programs was something natural.____Repair wouldn^t take much time at all.____