Ted wrote: >>> > But in Rev/MC, when you experience symptoms that may appear to be simlar to > HC corruption it may be more effective to look for different remdies. In > most cases, if you rebuild the card _exactly_, you'll reproduce the problem > exactly. > << > > If you just suggested user error, you certainly did it tactfully. :-)
I wish I wrote that well. :) Actually, I was thinking more about the nature of corruption and how in a system like Rev it's hard to make it happen (the only time it touches the disk is when you explicitely tell it to with a save command, and then it writes the whole file fresh in one clean pass). Your environment is hopefully less convoluted than mine, but with some of my older tools I have libraries that provide insufficient feedback to the routines that call them (thankfully I cleaned those up over summer for newer stuff), so sometimes I would have a behavior taking place that is not triggered by any of the scripts in my stack, but instead coming from one of my backscripts. In my less careful days, this sometimes made finding the true source of the trouble difficult. Given the rarity of corruption in a non-paged-memory system, I tend to try to exhaust all other posibilities before deciding it's corruption. If nothing else, the few times I've sent something to Scott Raney suggesting ut was corruption with the exception of one case of button corruption back in '98 in all other cases he proves me wrong. :) > Actually, in such cases, I'm praying that it's my fault. But it appeared not > to be--especially since these cards clearly exhibited odd behavior during the > most elementary of troubleshooting tests. Extensive assaults on these cards > from different angles (show, hide, move, put, etc.) convinced me that the > cards themselves were simply clinkers. So alas, the culprit wasn't I, but that > is always a bittersweet discovery, isn't it? > > Considering that I'm the only one who has responded about this particular > issue, it appears to be uncommon across the board. If it ever happens again, I > will send the offending card to RunRev for analysis. That's probably optimal. I know from my one instance it is possible to have a corrupt object, and if so having them examine the stack file should enable them to verify if thats the case. It may also be a bug, but if it is it should be reproducible. I had a case two years ago in which the SC-to-Rev converter faithfully copied object properties from SC to Rev, but in doing so it included a fillpat for a line object -- this caused a crash due to a bug in QuickDraw which throws a fit when trying to calculate the fill region (a line of course has no fill region). SC apparently special-cases such things when it's rendering the object so that having the value set doesn't trigger QD's error, and MC itself clears that part of the record when creating lines. But when building from a SIF export, the combination of properties was faithfully set in the object, and passed by MC'smore generalized C++ class off to QD, and QD choked on it. It drove me nuts trying to pin it down, but thankfully Scott took a look at the stack and the MacsBug stdlog I submitted with it, did some tests, and got me an answer within 24 hours. I just wrote a routine that cleared that prop from all of the line objects and it's worked swimmingly since. So while it seemed like corruption, the object record itself was intact and fully functional. Once Scott showed me how to get around that QD bug I was able to continue working happily away with the same objects. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
