IDE Interference (not just a another rant)

[xbury.cs at clearstream.com]

On 27.05.2004 17:51:54 use-revolution-bounces wrote:
>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...

Not so. My script proves that the IDE is interfering with your 
application's
messages and that is the crux of the issue. 

In my case I use the IDE as an application host (I rarely compile apps as
I prefer making RR tools to enhance RR development and context
productivity). 

>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.

I removed the auto-save - it was there to provide a safety against crashes
when using images in HTML. I dont rely on the auto-save plugin because 
it wouldn't work... See my previous plug-in issues - I dont trust them...

>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?

Irrelevant

>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...

irrelevant, futile ;)

>> 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!

You didn't get my point. But if I want a suspendstack event, it's my 
business
to have one as it is a feature. The point is that when you are in an IDE, 
the IDE
messaging should NOT interfere with your applications' events. When I 
choose a different tool, go to the message or to set an object's 
properties 
via the pallete, I am NOT leaving my application... In RR's case, it is...

This was not an issue in HC. THIS means that when you use suspend or other 

stack messages which may be interfered by RR's development stacks, you 
have to add a check level to make sure you are not in a rev palette or 
something...

Granted that this usage is rare...

Hope this clears up the confusion. The auto-save was just the command
that showed something was going wrong. Each time I went to the props
palette there was a 2 second GUI freeze, try it sometime to see how
enerving that can be ;).

Saving a 50MB stack in a blip is hard to believe!

4982 ms to save this stack on the EMC storage via GB net.
43ms on a local drive

The difference is enormous but in our company we are not permitted to 
keep data on the PCs for legal reasons (banking laws in luxembourg)

So the impact of this save functions was quite noticeable whereas at home
it wasn't... 

cheers
Xavier



Visit us at http://www.clearstream.com
                                                          
IMPORTANT MESSAGE

Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.

END OF DISCLAIMER