Yes, bjb007, I understand that frustration well. I've encountered it with just about every language I've learned, perhaps most strongly when learning C, since such a sparse language lends itself to abuse.
The challenge with learning most languages is that there's such a wide variety of ways to solve problems that finding the "best" (if any "best" truly exists) is uniquely difficult for a newcomer to discern.
I've been tempted to write a guide to learning Revolution by dissection for revjournal.com, but alas there's just far too much client work going on here right now to allow me the time.
1. Start with the projects designed for getting started.
While there's a lot of stuff in RevOnline, the variety in terms of coding style and structure can make it difficult to discern what's good to learn from and what's not.
Instead, I would suggest starting with the example projects provided in the Rev install. Take a look in the Resources folder within your Rev application folder. There you'll find two folders, "Examples" and "Sample Projects", and while I'm mystified as to why there are two different folders they both appear to serve the same goal: providing stacks designed for learning from.
2. Remember the message flow, and follow it.
A stack has a sort of "life cycle", determined by the order of messages it receives. It begins life when it gets a "startup" or "preOpenStack" message, and continues through various user events like mouseUp and menuPick, and finally ends when the last of its windows are closed and all pendingMessages have been processed or killed.
So tracing out the behavior of the project will start by looking for a startup or preOpenStack handler in the mainStack, or either of those or perhaps a preOpenCard message in the first card of the mainStack. I tend to do initialization in a preOpenStack message in the first card of the mainStack because it keeps the initialization in a place where it's only fired once, as opposed to being in the mainStack where any substack's opening would also trigger that preOpenStack message. You may find some variance there, but it's almost always in either the first card or the mainStack script.
Finding that will show you what the application's doing when it sets itself up. Once initialized, it's then up to the user-driven messages to determine what happens next (mouseUp in a button, menuPick in a menu, etc.). Looking at the code for those individual controls will tell you what to look for next, and I've found it much easier to find those in context, in the actual app, than hunting for textual descriptions of objects in a text file.
3. Know the message path, and that libraries are your friends.
Anything not handled in a control's script may be handled anywhere else in the message path. Most commonly, centralized handlers will be stored in the mainStack script, so they can be called from anything in that stack or any of its substacks.
If a handler is needed by objects which may reside in other stack files, it's common to have those stored in libraries or backScripts.
For info on those, this article may be helpful:
Extending the Runtime Revolution Message Path:
An introduction to using Libraries, FrontScripts, and BackScripts
in Runtime Revolution's Transcript Programming Language
http://www.fourthworld.com/embassy/arti ... _path.html
Once you get a feel for how libraries and backScripts work, you can make good use of the Message Box options for listing those which may be active at any given time.
4. Play.
Every bit as useful as dissecting others' stacks, and in some ways more so, is building your own. Start simple with things you know you can accomplish in a single sitting, like making a simple text file reader, and then add features to that in subsequent sessions to learn more.
When learning a new language I often wind up with dozens of half-baked things floating around my hard drive, a stack in which I experimented with file I/O, another for experiments with arrays, another for learning about custom properties.
By themselves these stacks aren't particularly useful, but by experimenting with new concepts outside of any context in which I'm expected to do real work gives me a freedom to explore and learn and refine without having to worry so much about how good it looks or whether it's feature-complete or even has sufficient error-checking (I've found that more than half of the code in most commercial apps is just error-checking and exception handling; if only users would do only what we want them to do our lives would be so much simpler).
It really helps to have a script editor which does lookups of handlers for you. I wrote my own (started as one of these experiments but grew into the tool Ken Ray and myself and a number of my clients use daily) which lets you select any token and type Cmd-"," and it opens the script where that command or function is defined and scrolls to that definition. If the selected token is a built-in one, it opens the Dictionary to that entry.
I believe this may be coming in a future version of Rev, and it's also available right now in Jerry Daniels' GLX2 (see
http://glx2help.ning.com/ ).
Hopefully these tips will help you get started learning Rev in a way that makes it the enjoyable process it ultimately should be.
FWIW, after pondering my own learning process and having done a lot of "Transcript as a second language" training over the years, I've found the learning curve often follows this pattern:
Day one: "What the hell is going on? Why doesn't anything work
like I expect? I hate this damn thing."
Two days: "Omigawd, the potential is incredible! If only I knew
how to use it all..."
Two weeks: "After reading the language guide and trying some
things out, I'm able to do truly productive work."
One month: "Now I can do productive work efficiently."
Three months: "With the flexibility of the language and the handy
tools in Revolution, I'm seeing slightly greater
productivity than in my formerly-favorite tool I'd
used for years."
Six months: "I love this thing."
One year: "I love this thing like no other."