IDE Interference (not just a another rant)

[MisterX]

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