This is just a copy and paste of the CPU 1005 problem I talked about on the devel list. It may very well be that this has the same root cause as some of the other excessive CPU bugs. I thought it best to just open up a new bug and track what I know for sure.
I have tracked down a repeatable way of pegging the CPU at 100%, and a hack that fixes it.
Any ooDialog program. Program extension is .rex, ftype association is the default of .rex associated with rexx.exe. A good example is the sample.rex program.
If you double click on the icon of the program, either on the Desktop or in explorer, the rexx process and the rxapi process will use 100% of the CPU. The CPU is split between the 2, but not evenly. rexx.exe takes more than rxapi.
On a dual processor system (including dual core) the CPU is 50 %. (Which makes sense of course, one processor is maxed out, the other is free.)
If you start the same ooDialog program from the command line, CPU is normal, always.
If you start the ooDialog program using rexxhide, CPU is normal. For rexxhide, what I mean is that if .rex is associated with rexxhide instead of rexx, then double clicking on the program icon does not use excessive CPU. Or if you set up the icon to start the ooDialog with rexxhide instead of rexx then CPU is normal.
In plbdlg.cls you have the run method. If I add in a do-nothing start, the problem completely goes away. As far as I can tell, always.
::method Run unguarded protected
use arg sleeptime
if Arg(1,'o') = 1 then sleeptime = 0
msgObj = self~start("workAround") <-- add
drop msgObj <-- add
do while self~finished = 0
::method workAround <-- add empty method
In private e-mail I have had a 3 people verify both the repeatability of the problem and that the work around fixes it.