printing code from example stacks

[jeffInt]

Hi all.

Newbie question.

I have downloaded some example stacks to experiment with and examine other peoples coding techniques.

Is there any way to print out all code within a stack. I am never sure that I have seen all the code in a specific project when you consider all the places scripts may hide!

I seem to remember that in MS VB there was an option to print all code - anything similar in Revolution?

Cheers

Jeff

[Bernard]

There is no way to do this that I know of in the current Rev IDE. I do see your point though, and I think that it would be a good thing to have. The best I can offer you as a quick pointer is to point you to the Application Browser, under the tools menu. You can see how many lines there are in each script/card/control.

[FourthWorld]

Why do you need to read all of the code?

[jeffInt]

Hi FourthWorld

As a new user I am concerned that I will not be able to view (find) all the code in a project. This may change with time as I become aware of all the places code can be written.

Also call me old fashioned, I relate to paper I can hold in my hand and not read from a screen. I guess this is very much an age thing.

Regards

Jeff

[BvG]

Knowing Mr. FourthWorld's age, I find the last comment quite amusing

Unfortunately there's no build in way to know where scripts might be hidden away, and I too think that's a back draw, although a small one. If you want to make your own, you can do it similar to this (untested):

Code: Select all

on mouseUp
  put "name of a stack" into myStack
  put 0 into cardNumber
  put 0 into controlNumber
  repeat for the number of cards of Stack myStack
    add one to cardNumber
    put the name of card cardNumber of stack myStack & return & return after allScripts
      put the script of card cardNumber of stack myStack & return after allScripts
    repeat for the number of controls of card cardNumber of stack myStack
      add one to controlNumber
      put "---" & return & the name of control controlNumber of card cardNumber of stack myStack & return & return after allScripts
      put the script of control controlNumber of card cardNumber of stack myStack & return after allScripts
    end repeat
    put 0 into controlNumber
  end repeat
  put allScripts
end mouseUp

of course then you also need to add the script of the stack, or even repeat for each stack that is open (using revLoadedStacks("application")). You could also add an if, which checks if an object actually has any script, and only list thoses which actually have one. Further bonus points for intending the list of objects and their scripts

Despite being a little slow, it at least will really give you each script.

[Obleo]

Can't you not just use the application browser. Open all the objects that show scripts attached in the script editor Then print script from the script editor. It maybe time consuming but i tried it and it works.

[FourthWorld]

It's precisely because of my "advanced age" <g> that I ask.

When I started out I too felt the need to dump scripts to a text file. Did that for quite a while. But the more I did it the less satisfying it was, trying to follow logic disconnected from its context.

In more recent decades I've changed from dumping scripts to a contextless text file to instead making tools to better dive into them in vivo.

I'm a big fan of learning by dissection, but like animal dissection if you only see the innards laid out on the table you don't learn as much as seeing them in their natural context.

So my question was an earnest one, and I feel one worth exploring further: What feels better about reading in a text file, and how can we get that same benefit from letting you explore the scripts where they live?

[bjb007]

Finding where the code is hiding is something
that I find annoying and frustrating.

There are stacks which I've got from RevOnline
which have "stuff" so well hidden that I simply
can't find it even though I know it must be
there somewhere.

Very off-putting when you're trying to learn.

There used to be an annual competition for
"code obfuscation" in one programming
language. Could we have one for Rev
programmers?

[malte]

Well, we did not have obfuscation competiotions yet, but there was some rev poetry floating around. Maybe we could revive that (Bonus points if it works with explicit vars on)

All the best,

Malte

[FourthWorld]

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."

[bjb007]

Thanks for the nice post, Richard. Generally it
mirrors my own experience and way of getting
to grips with Rev.

As I don't like hunting for bits of code I devised
my own ideas. Well, I am a simple country boy
so anything complicated throws me.

So I make my buttons go to a function in the
stack called "functionList" and that's a list of
calls to other function in the same "file".

So the code is nearly all in the same place which
I find convenient. I separate them with a line
and they're not hard to find but even easier with
the handler list on the left.

Early days yet. Expect I'll develop some bad habits
and no-one will be able to figure out what I've done.

[FourthWorld]

Putting as much of the code as practical into one place isn't a bad way to go at all. I tend to so the same thing, sometimes breaking up such collections into multiple backscripts or libraries to keep related functionality together, but still keeping the number of scripts I'm dealing with as small as can be convenient to sort through.

Best of luck in your new adventure, and please take advantage of this forum any time you have question. And you will. I still do all the time, ten Rev years later.

[briprince]

Hi all.

Newbie question.

I have downloaded some example stacks to experiment with and examine other peoples coding techniques.

Is there any way to print out all code within a stack. I am never sure that I have seen all the code in a specific project when you consider all the places scripts may hide!

I seem to remember that in MS VB there was an option to print all code - anything similar in Revolution?

Cheers

Jeff

Myself I simply copy and paste into notepad and then print!
I do agree that something as clever as this should be able to print the code.

[Bernard]

I realise this is a bit late for the original poster, but I thought I'd cross-post the information here in case anyone else is looking for this functionality in Rev.

On the 'use-revolution' mailing list Stewart Lynch mentioned that he'd built a tool in Rev to display scripts of Rev controls and it would even print out all the scripts in a stack. This is the URL to his tool: http://www.createchsol.com/ScriptReporter/

Here is a link to Nabble and the context in which this information came up: http://www.nabble.com/-ANN--RevDoc-home ... 35064.html , in case the other tools being discussed there are of use to someone looking to grasp a script they did not author.

[neo42]

Just for the heck of it, I tried opening a .REV file in a text editor. You can see ALL the code as far as I can tell. But as discussed above, it's easier to see it in context.

But seeing it in a text editor is a great way to expose the code for various reasons.


In my case, I couldn't find where a function was defined. Doing this let me see the code for the function even if I couldn't determine where it was precisely (though you probably can).


Maybe there are times you just want to see what the code is, but not where it is.


I don't have livecode on this computer, but did someone say you can see from the "application browser" how many lines of code each object has? I should check that out.