IDE Interference (not just a another rant)
b.xavier at internet.lu
Thu May 27 00:18:47 CDT 2004
> > 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
More information about the use-livecode