On 1/12/07 11:17 AM, "Richard Miller" <[EMAIL PROTECTED]> wrote:
> I wish it was a repeat loop, but if it was, it would certainly occur
> on all the computers we're testing on... or at least regularly on the
> same computer. This problem does not. It never occurs on half the
> computers and only occurs sometimes on some of them in the exact same
> spot. In other words, moving from a given card to another card will
> sometimes trigger the problem, and other times it won't. I can't see
> how that you be a problem with a repeat loop.
Ahh, that is a bit trickier.
The way it might be a repeat loop is that 'on opencard or closecard handlers
will contain a repeat loop or trigger one. Another possibility is that
there is a 'send' that has a pending message which depends on the current
card will trigger and the new card is missing some required info.
If this is not the case, then it could be something about the operating
system or path names on the hard drive. One example would be reading a file
into a variable, and if the path or file name was incorrect, the variable
would be empty and the program expects something to be there.
--eg.
put lineoffset(the short id of this card, idListOfLinkedCards) into pos
--where pos is 0 and you are expecting a positive integer
Perhaps you could install a 'on closecard' handler in the back and trap for
the particular condition in the 'exact spot', such as 'if the id of this
card is 2343 then breakpoint'.
What you are experiencing is my least favorite bug to track down.
The technique I resort to is writing a log file to produce an audit trail,
especially in my networking software that operates on different computers
and runs asynchronously. Very difficult to isolate the bugs.
--example -------
put tab into t
put the short date into dateStr
replace "/" with empty in dateStr
get dateStr & t & the short time
get it & t & var1 & t & var2 & t & var3 & t & the short id of this card
put (it & cr) after url ("file:"& dateStr&"logOut.txt")
--now if the force quit is necessary, the log file will have the last
successful handler call as the last line of the logOut file. The tabs are
so that Excel can be used to open the file for analysis.
Be careful of very large logOut file sizes of > 2 Mb. Slower performance
issues, but not crashing. I have had 34 Mb log files by accident and only
saw slow perfomance.
Hope this helps
Jim Ault
Las Vegas
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
