I've been trying some of the very simple examples shown in the ooDialog
reference manual - the things numbered 4.1.1 - 4.1.7.
Quite often - I'd say betwen half the time and three quarters of the time,
although the code does what you'd expect, it's very very slow. I find
things like a mouse-click on a button doesn't do anything, or if you click
once you may have to wait 2 or 3 or 5 or 20 seconds before the box closes.
I've also noticed the machine's fan coming on, and that made me look at task
manager. On an otherwise more or less idle machine, starting one of these
dialogs is frequently making cpu% climb to 100% - hence the apparent
slowness, I expect.
These are all execs being run by rexx.exe in a console window - there are
some 'say's and sometimes 'trace' statements in them. Most have a final
'parse pull waste' in them (instead of using rexxpaws) and I don't always
answer those, often just clicking the console window's X to shut the window.
Indeed sometimes a window is still open when I run another copy of a trial
exec. However I don't see any link between whether or not console windows
are open, or have been closed rather than the execs in them neatly coming to
an end, and whether or not an exec when run does so slowly.
It doesn't always happen. Sometimes the dialogs work fast and properly.
Does anyone have any ideas how I could find out what's wrong?
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
This seems to be a problem that has been reported here and there for
some time. I've never been able to reliably reproduce it.
It has several open bugs in the ooRexx project. You could browse any
of these to get some more information:
2303747 CPU LOAD 100%
https://sourceforge.net/tracker/?func=detail&aid=2303747&group_id=119701&atid=684730
1842856 CPU 100% when ooDialog program started through explorer
https://sourceforge.net/tracker/?func=detail&aid=1842856&group_id=119701&atid=684730
1346379 RexxHide pegs the CPU
https://sourceforge.net/tracker/?func=detail&aid=1346379&group_id=119701&atid=684730
Today, I think I might have fixed it. If you go to this bug:
https://sourceforge.net/tracker/?func=detail&aid=2303747&group_id=119701&atid=684730
I have attached to the bug a fix that you could try. It involves
replacing the OOD*.cls files in your installation with the ones
attached to the bug. There are 2 sets of files, one for ooRexx 3.2.0
and one for ooRexx 4.0.0.
If you do try the fix, I'd appreciate a comment in the bug report as
to whether the fix worked for you or not.
--
Mark Miesfeld
> I have attached to the bug a fix that you could try...
I installed the replacement files. After that I ran my seven sample dialog
execs 4 or 5 times each and all of them worked perfectly. Hooray!
However I then tried out some of the supplied sample execs:
a) samples\oodialog\dlgAreaDemo.rex
- was sluggish responding to a click on its OK button, the first
time I tried it. On subsequent runs it was sometimes fine and
sometimes slow, but never dire.
b) samples\oodialog\ftype.rex
- every time I run this as soon as the dialog box appears asking me
to choose one or other option, cpu% climbs to 100%, taking 2-3
seconds to do so. CPU use is split between 'System' at 45-50%,
rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which
I think is the internet traffic monitor for Zone Alarm Pro) at
around 30-40%.
I don't know why vsmon gets busy, not least because as soon as
ftype.rex is stopped, vsmon.exe loses interest...
c) samples\oodialog\calculator.rex
- like ftype.rex, cpu hits 100% as soon as dialog is displayed
Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS
files in the samples directory. And of course, I only updated the ones in
ooRexx\ itself. Why on earth are there copies here too?
There are also copies in \samples\oodialog\source.
As soon as I renamed the ones in the samples directory - just so they'd not
be found - the samples described above now work fine.
> If you do try the fix, I'd appreciate a comment in the bug report as
> to whether the fix worked for you or not.
OK; thanks for finding a solution!