Sarah, > > > Tracking it down wasn't much help because the message > > watcher threw me off thinking the problem was the TableManager > > (sorry Jan)... Besides the fact that the message watcher is nearly > > useless, it throws in all the RR's messages to confuse you and > > doesn't tell you where the message came from... The more stacks > > or windows (scritp editors for ex.) you open, the more messages you > > get to confuse you... > Click the Suppress button in the Message Watcher and you have all sorts > of options for telling the Message Watcher what messages to ignore. > When a line appears, select it to see where it came from.
I did try that but there is no source for the RR events... There not hard to find though... > > Anyway, my stack was really slow all the time and the problem was > > untraceable... Then I noticed that a message suspendstack was > > saving the stack at each suspendstack... Nothing wrong there > > except that whenever I went to the revprops or revtools or revmenu > > palette, my stack would get a suspendstack event!!!!!!!!!! > It seems to me that you would have a lot more cause to complain if > going to a different stack did NOT send a suspendStack message! > However, if your save stack routine is causing you problems, that may > be due to your saving method. If you are using the internal "revSave" > handler either in a script or by calling the Save menu item directly, > it throws up a dialog box telling you what has been saved. I wasn't using those. They're very slow... > This box > stays open for 2 seconds but you can of course edit the script for that > if you want. If you use the simpler "save this stack", you will not get > the dialog and saving should be so fast as to be undetectable. The > disadvantage is that it does not compact the stack so if you have been > adding or deleting lots of objects, you should do a menu save every now > & then. but thanks for the tip... > > Since RR is ultra slow, ultra-cpu-hog, I couldn't be get more and > > more irritated... On a 2.8 MHz P4 512MBs, this is a shame, and > > a real bummer for productivity... > > > > Why would a 10 K stack take 5 seconds to save and hog your CPU > > at 55 % (or 99% hog on a 1.8MHz P4...)? > > > > IS THAT NORMAL? > > > > This is NOT normal behavior and I believe we are all affected! > No it is not normal and no we are not all affected. I think you are > blaming Rev for something that you have added as the default > installation of Rev is not "ultra slow" and is not an "ultra-cpu-hog". > Check what stacks you have in use and whether you have added an front > or back scripts. Something you are doing is causing this lack of > performance and leading to your frustration. I have numerous plugins > running constantly, both my own, Rev's and those contributed by others > and I have none of these problems. I dont use any plugs or front/backscripts yet... 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... 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... Thanks for the help though Xavier _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
