There's no place like Home
ambassador at fourthworld.com
Thu Jun 7 10:23:38 CDT 2007
> 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
> 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
> 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
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
> 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
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.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode