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.
This situation is not, however, absolutely clear. For example, many
users on this list have been using X-Talk for years, and naturally their
expectancies and preferences are forever conditioned by this experience.
My own case is different. I came directly from VB6, and naturally I am
the victim of similar conditioning. Some of Rev's characteristics which
appear to me to be strange and unconventional are natural, normal and
indispensable to X-Talkers. This is a great exercise in trying to see
something from other people's point of view as well as our own.
Bearing the above in mind, I would like to put forward 2 ideas that
would help my own workflow as an ex-VBsixer.
To me, the "browse" tool is essentially the "RUN" button whereby I can
test the running of my project as it stands so far. 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. 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.)
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, 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.
Regards to all,
Bob Warren
_______________________________________________
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
