dsc at swcp.com
Fri May 5 17:40:13 CDT 2006
On May 4, 2006, at 7:47 PM, Cal Horner wrote:
> A stand-alone app doesn't delete itself out of the Windows Task
> Manager list
> when the stand-alone app is closed. The app remains in the
> processes list
> and each time it is used another copy is left.
This might be an old, old Rev bug from before bugs were on bugzilla.
I wrote the report below over four years ago. I don't know if it
applies now. Also, I was a Newbie. See #6.
I have some problems with "read from process." I apologize for the
missing detail. I might be doing something silly that has caused
some of these, but I think most are related to bugs.
1. Delay time doesn't work how I expected
I open process "ping -n 10 127.0.0.1", read from the process until
end and with a delay, then close. I vary the delay. I vary -n at
times. The -n switch controls the number of pings (and report lines)
which are sent about a second apart.
The actual time (measured in ms, using milliseconds()) that the
execution is in the read is less than the specified delay and can be
a small fraction of the request. This occurs even then the specified
time is less than the ping time (process execution time). The number
of lines read seems to be roughly consistent with the time the
execution is in the read, but not always.
2. Read when no data at start hangs
A read (until end in 3000 milliseconds) from a process that does not
generate output for a while at at start of the process hangs
Revolution. Revolution does not paint the content of windows.
This is contrasted with the tests in #1 above in which even a small
amount of data read by the delay time will cause the read to complete.
3. Immediate read without delay hangs
Read from process "ping -n 10 127.0.0.1" (until end, no delay) right
after open hangs Revolution even though the process completes in 12
seconds. The window contents are painted in this case.
4. ^. in "read from process" sometimes gets memory fault
I have gotten a memory fault in this situation but didn't write down
5. Closing of error window from ^. in "read from process" gets fault
One time the runtime error window from ^. in "read from process"
caused a memory fault when closed. (Instruction at 0x004a6553,
location at 4 could not be read)
6. Process locks up (open, read, close)
Usually the ping process exits in tests in #1 above, even when the
process is closed before or after the actual end of the function.
However if -n 50 is used, and the process is closed much before the
end of the pings, then the process hangs and will not exit. It has
to be killed.
(I can get ping data just fine with the shell function; I'm just
trying to learn about "read from process" and the ping is handy.)
More information about the use-livecode