Enhancements in your opinion?

[Richard Gaskin]

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