Bob Warren wrote:
When submitting enhancement requests, I think it is a good idea to
obtain some idea of the opinion of other users (of all types) before
actually putting it forward concretely. Even if an idea is new, people
are likely to accept it if it helps the flow of their work. On the other
hand, nobody wants to clutter up the Rev IDE with options that only
please a few users some of the time.
Agreed. Between those, duplicates, and cases of simply not reading the
docs, about 15-25% of Bugzilla entries are just noise.
To me, the "browse" tool is essentially the "RUN" button whereby I can
test the running of my project as it stands so far.
That's not truly the case. Rev has multiple tool modes, just like most
layout programs. The Browse tool could be considered the "normal"
behavior, but if you're making a program that supports layout you can
use the pointer tool also.
Tool modes are not proprietary to the IDE; many of us make apps which
use the pointer tool, paint tools, and other modes. See the Dictionary
entry for the choose command for details.
The difficulty in imagining the pointer tool as "layout" and the browse
tool as "run" is that it overlooks what is perhaps the central
difference between working in Rev and working in more traditional tools
like VB: Rev is always in runtime.
There is no distinction between "edit" and "run" -- the engine is always
working, always sending and handling messages, though the messages sent
will sometimes differ depending on the current tool.
However, because doing this can cause my program to permanently
acquire properties that it did not initially have, before
clicking on RUN I need to save my project in its "clean" form
so that I can "REVERT" through the message box to the original
state of the program.
That's not a native engine behavior; the engine only affects built-in
properties. Anything that affects custom properties is a design
decision in the IDE. The Rev IDE was created during a time when the
engine was owned by another company (MetaCard Corp.), and at the time
the only way to implement things like the Profile Manager was by using
custom properties.
RunRev has long since acquired the engine, and I'd like to believe that
anything the IDE does to stacks will eventually change to use built-in
properties, leaving the user-defined properties to be defined by the
user. It also performs colorization on the fly, so it never needs to
cache a copy of the script in a custom property.
The first IDE for the engine from MetaCard Corp. never adds or modifies
custom properties. With the acquisition the MC IDE became open source,
and is maintained by a group of volunteers. While its installation is
somewhat cumbersome, any Studio or Enterprise licensee can use MC with
engine v2.7 or later. A more streamlined installer for MC IDE is
forthcoming.
There are also at least three other IDEs in the works, and to the best
of my knowledge none of them alter custom properties. News on those
will no doubt be posted here as they become available.
In the meantime, Chipp Walters has made a handy plugin, altCleanStack,
which strips Rev's custom properties from a stack:
<http://www.altuit.com/webs/altuit2/altPluginDownload/Downloads.htm>
Also, since the Rev IDE considers my main stack to be already "LOADED",
handlers such as "on openStack" will fail (unless special arrangements
are made for their re-execution), which is not convenient to the
running and testing of my program "from scratch". (Incidently, this
is completely different in VB6. Actioning "RUN" means exactly "simulate
the running of the project as though it was a standalone", which
implies the re-execution of handlers such as "Form Load" in VB6
terminology.)
See where the expectations of similarities between VB and Rev will get
ya'? :)
Because Rev is always running, if you need to re-initialize your stack
you can do this in the Message Box:
send "openStack" to this stack
With most of my projects I make a simple palette plugin which send any
messages I need (and quickly opens specific stacks and scripts and other
handy things -- takes only a couple minutes to make your own custom
handy tool).
While I recognise that many users appreciate the "raizon d'etre" of the
above arrangement, and are happy using "splash screens" etc. in order to
get around the situation
The "splash screen" that most people talk about here involves something
that *is* similar to VB: a Windows application cannot modify itself
while its running.
People use the splash screen-as-standalone approach for two reasons:
1. To allow other stacks to have changes saved at runtime
2. To allow dynamic downloads of application components which can be
updated without having to quit the application
, I would like to tentatively suggest
introducing the following OPTIONS:
-------------------
1) A new handler in 2 possible forms:
on run
on browse
2) A new button called "Standalone Test" or just "Test".
-------------------
The handler in 1) would be executed when the operator clicked on the
toolbar's "browse (run)" button. It would also be executed on a single
occasion at the startup of the standalone version of the program.
The action of the button in 2) would be to a) hide the project stack
etc. in the IDE; b) compile the standalone in temp form; c) execute the
temp standalone by means of a shell call; d; re-show the project stack
etc. upon termination of the shelled temp standalone.
What do you think? I anticipate that I will probably learn a lot from
your replies.
I don't know that the new message is needed, but I agree that a way to
have a menu item which closes a stack and re-opens it fresh (to trigger
the opening sequence of messages -- preOpenStack, preOpenCard,
openStack, openCard, etc.) would be handy.
Here's a question: What do to with the startup message? The engine
only sends this when an application first starts, but since the Rev IDE
is the application while working within it that message doesn't find its
way to a stack.
Can it safely be sent to a stack before opening the stack to get the
same messaging sequence as in a standalone?
I never use startup myself so I'm of little use on that one.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
