Enhancements in your opinion?

[Bob Warren]

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