Xavier,
See my previous message response with the suspendstack script. It's not a problem per say, true but it is a problem when implemented where the RR events cause a serious slow down each time you edit an object feature via a Revpalette and a suspendstack message is sent to your stack...
If you're gonna flame Rev for being slow, you should really at least consider that your own added script is at the crux of the issue...
Is there any reason you can't change your auto-save implementation? Saving stacks in Rev is quite fast, but you're probably causing havoc by doing it on suspendstack- unless you can provide some evidence to the contrary. I save 50MB stacks all the time and it's no more than a blip on a 500Mhz iBook.
How about using a simple timed auto-save, say every 60 seconds? What's the use in saving on every suspendStack when you have a screen full of windows and palettes?
If you really want the tightest, instant auto-saving you'll probably have to insert a slew of event and setprop handlers in a frontScript, but frankly I don't think it's worth having...
Should the suspendstack be sent to the stack each time you edit an object causing a save? One missing feature (no blame anywhere) is the function stackwaschangedsincelastsave()=true|false... The other is that the suspendstack should be ignored while in the GUI design mode of RR...
Yes, of course it should be sent. That's how the message is defined. Nobody said to put a save handler in there!
- Brian
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
