File Corruption

[Sannyasin Sivakatirswami]

Agreed. One must be specific

One verifiable "corruption" issue I have definitively diagnosed is that 
the IDE will create spurious code in the cRevGeneral custom properties 
that are attached to any given object.

Two known instances of this have been

a) an instance where a Rev IDE custom prop in a stack referred to an 
older version of the program which was not on disk and which was other 
than the current engine/IDE wrapper under which the stack was opened.

b) a second instance (found only yesterday) where, during a lock up, 
the IDE does not update the "script" custom prop for an object in this 
case a button... tempScript was correct (i.e. it had the changes I had 
made in the script saved correctly in the "tempScript" prop for the 
button) but "script" carried and older version of the script.

Now, this manifested after reboot of Rev, as a "object not found" in 
the script debugger where the previous script referred to a fld 
"Reminders" instead of button called "Reminders" . But, had i been in a 
run time mode, it would have just failed...

Solution was simple. add a space to the script, and force a new "apply" 
to update the custom props.

so, one solution for this kind of corruption (where in fact the data in 
the stack is still pristine/OK) would be a

"Clean up and refresh all RevCustom Props"

I suspect -- a broadside generalization! ;-) --

That the revCustom props may be getting more mangled than we realize.

But, to be fair, I get as many or more "unexpectedly quit" instances on 
OSX from Apple's own Mail.app and other apps as I do in Rev.  Only 
Rev's are pretty predictable.  which is actually better!

Sivakatirswami




On Tuesday, June 24, 2003, at 07:09  AM, Richard Gaskin wrote:

>> Well look, I don't want to quibble about terminology. Isn't it 
>> possible
>> for the IDE to corrupt its own internal data structures?
>
> My interest in re-examining the use of "corruption" was less a 
> refection of
> my admittedly curmudgeonly nature than a sincere desire to see a proper
> diagnosis of the root cause.  If we attach a label to an issue before 
> fully
> understanding the cause, we risk overlooking other options that might 
> lead
> us to the solution.
>
> I agree that it's too early to determine that corruption of the object
> within the file did not occur, but with such a low incidence rate on 
> record
> it may not be optimal to focus on that.  We can't rule it out, but we 
> can't
> settle on it either.  It seems we need to keep our eyes open to wider
> possibilities.
>
> What's most baffling to me is that the cloned object exhibits no 
> erroneous
> behavior; I would have expected that if a problem existed in the 
> original
> object it would be carried over to the clone.