IDE Interference (not just a another rant)

[Monte Goulding]

I missed your post to me somehow so am responding to what I can see in
Brian's messaage.

>> Monte, I saw that MC was also afflicted with thi issue. But IMOHO the
>> Rev
>> messaging
>> should not interfere with applications in development - As I developped
>> XOS, I used
>> extensively the HC messaging to intercept all stack events from the
>> hierarchy top -
>> much like frontscritps would and will soon - the key point was not to
>> interfere with other
>> stacks and this required particular checks everywhere...

I don't understand what you mean by "interfere"??? It's not the IDE stacks
that interfere with your stack it's the engine sending your stack a valid
message that is quite useful in a number of contexts. It's your stack that
is handling the message and doing something slow with it.

>> In a multicard environment, a single card script would not sufice - if
>> I
>> read you right...
>> That's why it was in the stack script. Note that there is an advantage
>> in
>> this feature...
>> It simulates the HC saving which was part of its robustness...

No, you either don't read me right or don't understand the message path
implemented in the engine. A message sent to a card if not handled will
eventually make it's way to the stack where you can handle it. If you check
the documentation you will note that the suspendStack message is also sent
to the current card of the topStack.
>>
>> The problem was:
>> - saving over the network is 100 times slower...
Your problem not Revolution's. If you don't understand why saving from RAM
to disk on a local drive is slower than RAM to disk on network storage then
I'm sure there's plenty of books and websites that will explain it out
there.

>> - choosing a tool or changing a property sent a save which I forgot was
>> there causing these freezes...
Hmm... moving to another stack in the IDE does not send a save. It sends a
suspendStack message (and a resumeStack message). Your code sent the save.

Cheers

Monte