Force interrupt

[Richard Miller]

Jim,

I believe you gave me the clues I needed. It looks like the way we  
used the Send command in a few places was the problem.

Thanks!
Richard



On Jan 12, 2007, at 4:13 PM, Jim Ault wrote:

> On 1/12/07 11:17 AM, "Richard Miller" <wow at together.net> 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution