There's no place like Home

[Richard Gaskin]

Shari wrote:
> The first thing I do upon launching Rev/MC is click the Tool btn on 
> the Home stack to open the Tools menu, then close the Home stack.

Me too.  One more reason to have any Home stack operate like RevOnline, 
with an option to let the user determine if it opens on launch or not.

> One thing I would not want is more front and back scripts added.  I 
> recently spent many hours trying to find out why my own frontscript 
> mouseup handler wasn't occuring.  In the end, I had to go thru every 
> btn (and there were a lot) that called my frontscript, and do this:
> 
> on mouseUp
>     myMouseUp
> end mouseUp
> 
> I renamed my frontscript mouseUp handler to myMouseUp, and it fixed 
> the problem.  But the problem shouldn't have existed in the first 
> place.
> 
> What was even more frustrating, was that my use of mouseUp in my own 
> frontscript has worked fine for years, and I don't know what broke 
> it, except to wonder if the newer versions of Rev/MC did it.
> 
> We don't need more frontscripts interfering with our own!  Vote = No.

The MetaCard IDE uses only a single frontScript and backScript to drive 
itself, and to the best of my knowledge its mouse handlers haven't been 
modified since Scott Raney wrote them back in the day.

Messages are arguably the most important category of tokens in the 
language, as they're our five senses that let our scripts know what's 
happening in the world.  In the absence of pointer-tool-specific 
messages (requested at 
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2606>), any IDE will 
need to trap mouseDown, mouseUp, etc. to update property inspectors and 
such, but this sensitivity to the critical role of messages keeps MC's 
handling of them as light as possible.

So given all that, and the care RunRev puts into maintaining the 
integrity of messaging in the engine, I'm surprised you encountered a 
change in behavior between engine versions.

If this remains an issue we should continue poking around with this on 
the MC list.


> There should be docs of the same caliber as the old Hyertalk 2.2 
> book.  That, and the Complete Hypercard Handbook, were the two best 
> sources of documentation I've seen as far as a well-written how to. 
> Every function and command should have detailed code examples for 
> every scenario of use of that function/command, and the info should 
> be easy to find.

Rev's documentation isn't too far off that mark, since the original docs 
were written by the same person who wrote most of "HyperTalk 2.2: The 
Book", Jeanne DeVoto.

But Rev 1.0 was a long time ago, and a lot it's been revised and a good 
many new tokens have been added since.  And some of the most helpful 
stuff she wrote, like the Cookbook stack, have long since been removed 
from Rev, which is too bad because there was some darn useful stuff in 
there.

FWIW, I've recommended Jeanne to a client to write the documentation for 
two products I develop, and we -- and our customers -- have been very 
pleased with the results.  If anyone here needs a tech writer I would 
recommend her.


> NEVER assume your user knows xyz when writing an example or answering 
> a question.

I agree that all the IDEs could use some enhancement to the docs, 
perhaps MetaCard's even more so given its age and historic caudience 
focus.

At a minimum I'd like to see what could be done to be able to call up 
Eric Chatonet's excellent Search tool within MC.  It's probably the most 
comprehensive search around, able to pull in stuff from an amazing 
variety of sources.

We don't currently have an owner for the documentation components in the 
MC IDE, and if one of the open source advocates here would like to take 
that one we'd love to have them on the team.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com