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.
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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
