Re: SetDebug xxx.txt
- Sheri, It is my bostonian accent again...
The clip already worked in 4.95, for weeks, in a slow PC. But
accessing files in a fast (other) PC, in a small house network.
I purchased 5.30, installed in other PC, fast, in the same network.
And accessing the same files in the fast computer, in the newtwork.
In the 5.30 don't worked, and I finded that because using a .csv
(read, write, read fields, etc) he stop. Therefore, to test/debug I
included a Delay 10 after each read, write, and worked fine,
regarding the .csv file.
In both cases (4.95 and 5.30) the data files was always in the fast
Don't make sense, for me. But is true and using, in both cases, a
vanilla code. Worked ok in the slow but needed delays in the fast
(?), both accessing the same files located in the fast computer,
both computers in the same small network. As you know, in
read/writes the computer normally wait to complete the operation
after go to the next code line, so, I don't understand why the
5.30/fast work only if I include delays in read/wtites and the
4.95/slow don't needed that.
--- In email@example.com, "Sheri" <silvermoonwoman@...>
> --- In firstname.lastname@example.org, "abetsent" <backup2abet@> wrote:
> > > 3. After each file reads and writes, fields reads, I included
> > > small Delay 10.don't
> > >
> > > And he worked fine in the second (fast) computer. In the slow
> > > computer, he stoped in every run. In the fast computer, he
> > > stoped in 30 runs. I am convinced that was the problem.there
> > >
> > > Any comments? It is ok now, this is only to understand the
> > > original problem.
> If the ^!Delay causes the slow computer to stop, it sounds like
> were ^!Keyboard commands whose critical timing failed due to thethe
> delay. AFAIK processing of clipcode doesn't stop and wait for all
> keystrokes to be delivered. So on a fast computer, the progressionof
> the clip may get too far too fast, and fail to have the criticalkeys
> delivered when needed. OTOH on the slow computer, a delay can makethe
> same keystrokes get delivered too early in the course of clipbut I
> execution. Possibly some types of file I/O could need a ^!Delay (to
> allow time for hard disk activity to completed before continuing;
> again it is the fast computer more likely to need such a delay),
> would expect a delay in that case to work fine on both computers.you
> Can you create and post a small clip that has the same issue? When
> said it worked in 4.95, did you mean it worked in 4.95 on both
> computers without the delay?