First I want to say that even though my tone is not apparently RR friendly,
im only trying to point out the obvious in a rudimentary way... Im not upset
or raving to get RR aknowledge a bug, just trying to point out a flaw in
design within the IDE and seeing if others have seen this and why it's
there. Thanks to Jan and Richard, the solution is apparent. Yet the error
will come back im sure...
Well if you know your tone is not Rev friendly, but I digress... I hope nobody's actually upset- I'm not. Perplexed, but certainly not upset =).
Im particularly affected (note I haven't entered a bugzilla!) because 1) I
rely on these stack-script-level events "extensively"; 2) my environment
usually works within stack events to interact with other stacks; 3) Im
editing and working in the IDE for the most part; 4) MC is also affected yet
hadn't noticed for the past 4 years until our company decided to do some
serious and relatively unnessarry network segregation (IOW it's hell planned
the wrong way!)
I still don't see the bug. suspendstack is well defined, and you point out MC has been that way for those 4 years (and more). It's not an IDE message, it's an engine one- and it's working properly. It's probably just the wrong message to use as a save stack trigger.
I used to run HC on diskettes... And here we have a FAST network, all
copper gigabit (about 4 GB/hour avg transfer times)... I still can't
explain why it takes 30 seconds to save a 1 meg stack. Could be the
AV or FW, its hard to say... It sure is excrutiatingly slow...
But its not the net. When I copy data from elsewehere, it's quite zippy.
Copying files and saving an open file from memory to disk are different operations.
That why I suggest saving to the local disk and _then_ copying that file to the network volume, perhaps in the background of ever so many saves.
Now about the events, logical assumption is that the IDE event model should not interfere with the application in development events. This is why RR has a secondary event level usually named rev[eventname].
Wouldn't it be worse if suspendStack stopped working as documented whenever the IDE was present, because the IDE stacks were specially excluded from the rules? What if your stack needed the actual documented behavior- you'd be at a loss to have anything work right without first suspending the development tools.
But as Jan mentioned, palettes are stacks.
What I didn't expect is that a palette, let alone the tool palette would
cause a suspend stack.
Fair enough- but it's not a bug, it's documented chosen behavior.
If RR could speed up our network, EMC, Cisco and HP would be out of business!
I hope they find out how ;)
Again I didn't expect that changing an object property or picking the button
tool
would engender a suspendstack event... This was a left over message I forgot
about...
Understandable, but hardly a Rev problem- see above.
The bottom line is that through this "experience" we have seen two things:
1 - your stacks should be protected from IDE events IF and ONLY IF you
decide to use
the stack messaging system as an event trigger - which in the case of a
standalone app is futile but in the case of a running system based on the
IDE causes HAVOC. Im testing RR in our production environment and this issue
has proven counter productive (dont you like Tuvoc talk?).
So the IDE should dynamically suppress engine messages based on which ones your stack might be using, just in case you didn't want your stack to interact with other stacks if they are part of the IDE? Sounds pretty messy to me...
Nice assumption but I need these programs from anywhere in the network
including in different network segments with Firewalls in between... More RR
saving testing to be done next week...
Right- but the point wasn't to only save them locally, it was to make local saves more frequently and then copy those files to the network volume- if copying files is actually much faster than saving directly to the network as you described above, this might help. Surely it's ok for a few minutes of work to be cached locally, and you could even run the copying to the network in the background while you continue working by using shell() to do the copying.
- Brian
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
