Hi Len,
Ultra-Beginner is of course an ambiguous term, especially when referring to someone who already has a lot of experience programming.
Here are some thoughts regarding starting a Rev project:
1) This one's a bit controversial, but here's my best thinking on Interface design and Revolution. If you're more of a C/VB/Basic programmer, think of a stack as a window. Use only as many cards as you want interfaces. IOW, I typically only use 1 card per stack, as typical applications behave similarly. The notable exception to this rule is when creating wizards, where multiple cards are a great asset. Actually, I lied, many times I use two cards, but the second card is used to store icons and graphics and other parts and is never seen.
2) Separate your interface and business logic from your content. This is contrary to the Hypercard notion of storing data in the card and saving the stack. Save your data either as invisible data stacks or text/binary files. This does a couple of things. Foremost, it ensures application integrity. Because your application doesn't need to be saved with the embedded content, you never have to worry about your stack becoming corrupted as it's never saved. In fact, the Rev prefs stack is an example of a stack which frequently gets corrupted and requires a complete reinstall of the Rev IDE. Bad design.
3) Try and stay away from frontscripts and backscripts unless you absolutely need them. Frontscripts can be a pain to debug while IMO library stacks are better than backscripts for a number of reasons including: 1) easy to create/edit and install in multiple projects; 2)The number of libraries you can include is much greater than the limited number of frontscripts/backscripts you can have.
4) Try and encapsulate business logic you'll use for many projects into a few custom libraries you use/maintain.
5) Check out Richard Gaskin's excellent article: "Extending the Runtime Revolution Message Path"
http://www.fourthworld.com/embassy/articles/revolution_message_path.html
Must reading for new RR programmers.
6) Get comfortable with searching the use-archives. Again, Richard has a quick link to it at:
http://www.fourthworld.com/rev/index.html
7) Remember, a standalone cannot save itself. If you are going to use stacks to store data in, be sure and have the standalone open the stacks independantly (not subStacks!). Many of us use a 'splashscreen' approach where we put a minimum splash screen in a standalone which launches the stack(s) which are the main application.
8) BEFORE you get frustrated, try and communicate concisely and clearly your problem on this list. Chances are someone can help within a few minutes.
9) Program TOP-DOWN. Again, controversial, but I prefer creating my screen layouts first, and then hooking up the functionality from there. It's served our company well and is more of an XP (Extreme Programming) approach.
10) Use altArchive plugin. It's one I wrote many moons ago and has saved me (and a few others) a lot of pain. It saves your current project, and archives a sequential copy of it in a local folder. It's free and can be found at:
http://www.altuit.com/webs/altuit2/altPluginCover/about.htm
11) Keep your handlers to yourself. IOW, keep handlers as far UP the message path as you possibly can. If it can fit in the button script and isn't needed elsewhere, leave it there. Learn to use locals and custom properties (very powerful) instead of globals.
12) Another R Gaskin gem: Create a StripAndShip handler which you can call before closing your stack which will reset all controls to native states.
13) Learn how to use "put URL" to read/write local files, access stacks off of webservers, etc. The put/get URL command is one of the most powerful commanda in Transcript. Also, learn about chunking.
get character 1 to 3 of word 5 of line 12 of field "myField"
is also extremely powerful! You may find you don't need to use as many arrays as before. Just put things into lists and access them using chunk terms.
14) Learn how to use "repeat for each" instead of "repeat with x=1 to tNum" as the first is *significantly* faster!
15) Many of us store data invisibly in fields for access. For instance, say you wanted a person to choose a name from a list and and then go to the default website for that name. For instance choosing "Chipp" may take you to:
"http://www.altuit.com/webs/altuit2/RunRev/default.htm";
and choosing "Richard" takes you to:
"http://www.fourthworld.com";
You could create a list field 70 pixels wide, and put:
Chipp & tab & "www.altuit.com/webs/altuit2/RunRev/default.htm" into line 1 with Richard & tab & "www.fourthworld.com" into line 2
Set the tab spacing for the field to 70 so that the web address is NEVER seen in the field. Then when someone clicks on the field you have a simple handler:
on mouseUp put the hilitedlines of me into t if t is "" then exit mouseUp set the itemDel to tab put item 2 of line t of me into tURL revGoURL "http://"; & tURL end mouseUp
Of course there's other ways to do this as well, but when you start adding multiple tab items to the same line, this technique becomes very powerful.
Well, that's at least a start. Hope you stick with Rev. It's a very powerful 4th generation programming environment, but with a steep learning curve.
best,
Chipp
Len Morgan wrote:
Hello All,
I've been a programmer since the mid 70's. I've used and/or tinkered with all of the "normal" procedural languages (C, Tcl, BASIC) and even some "ab"normal ones like Forth. I consider myself a pretty good programmer and have been told I'm fairly bright in general. I've had Revolution for a couple of weeks now, and I just can't seem to get my head around the "methodology" of using Revolution.
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
