<HTML><FONT FACE=arial,helvetica><FONT SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0">In a message dated 28/08/2003 06:15:21 PM GMT Daylight Time, use-revolution-request@lists.runrev.com writes:<BR>
<BR>
> Can you explain how the ScriptersScrapbook app is "different"? Also, any <BR>
> other folks that have links to good examples of coding style and <BR>
> methods, I would love to see them.<BR>
<BR>
The main window is dynamically set on launch, that's all. It's designed to be a 'use whilst you work' tool, so is designed to be impervious to the authoring environment. Nothing more.<BR>
<BR>
> I get the feeling that as powerful as RR is, there are plenty of ways to <BR>
> abuse the language, like Perl. The voices of experience would help <BR>
> here. I.e., is it better to tuck little snippets of code away inside <BR>
> lots of objects, or collect the code all at the main card level (as <BR>
> ScriptersScrapbook seems to have done).<BR>
<BR>
Anything used more than once should have its own code. Easier to maintain, track and manage. Shared handlers at stack level allow background, group and card-level modifications.<BR>
<BR>
I collected the following tips and tricks over the years... Feel free to disagree, add or ignore.<BR>
<BR>
- Don't trash accepted interface expectations. Refer to the interface section of the Power Tips project bundled with SuperCard, the Mac HIG and Win HIG.<BR>
<BR>
- Read the Tech Notes supplied with SuperCard and the Concepts & Techniques stack supplied with MetaCard, and the extensive documentation with Revolution. Lots of useful tips.<BR>
<BR>
- Any operation used more than twice should have its own handler.<BR>
<BR>
- Balance length of handler with compiling time overhead and the shareability of smaller, more quickly compiled, utility handlers and functions.<BR>
<BR>
- Compact code is faster to run, but harder to unravel when you need to analyse it later. Use comments to explain "why" as well as "what", if not "how" as well.<BR>
<BR>
- Keep a list of all global variables, and put empty into them when you close the project for clean housekeeping.<BR>
<BR>
- Use a consistent naming convention: g_GlobalName, t_LocalName, a_ArrayName. Some folks also name built-in handlers and function with a lowercase initial letter and their own with an uppercase leet eg 'on mouseUp' but 'on ShowItems' so things can be more easily identified.<BR>
<BR>
- Collect all the data first, then operate on it rather than collect, operate, collect, operate.<BR>
<BR>
- Make handlers and functions as general as possible. You can then re-use them.<BR>
<BR>
- Make sure that anything passed to a function or handler can be handled, however unlikely, including empty perameters.<BR>
<BR>
- Keep a standard set of navigation handlers eg "goPrev". Adjustments are easier to implement.<BR>
<BR>
- The larger the number of items on a card, the slower it opens.<BR>
<BR>
- The larger the amount of styled text, the longer any operation on it takes to process.<BR>
<BR>
- Use draw objects rather than bitmaps... they load faster.<BR>
<BR>
- For a fast transition to a card with a large colour bitmap, put it in a separate window and open it invisible before showing the window.<BR>
<BR>
- Lock screen speeds up many operations, but frequent unlocking has a time overhead which increases with the number of items to be redrawn.<BR>
<BR>
- Setting lockMenus to true in SC speeds up menu operations by a factor of 20.<BR>
<BR>
- Functions with brackets take longer than functions without brackets when you have the choice eg "topWindow()" is slower than "the topWindow" in MC.<BR>
<BR>
- Calculate once, and use a variable thereafter.<BR>
<BR>
- Add a zero to variable names in calculations to force them into binary format. Subsequent calculations are very much faster since they don't have to be interpreted as text.<BR>
<BR>
- Variables are much faster to access than other containers.<BR>
<BR>
- The more the variables, the slower the calculation; "add a to b" is faster than "put a+b into c" or "put a+b into b".<BR>
<BR>
- Prefix global variables eg g_VarName. They are then easily identified.<BR>
<BR>
- Put names in quotes. They are faster to compile since they are not checked as variables first, and you cannot unintentionally confuse them with a variable of the same spelling.<BR>
<BR>
- Beware of embedded repeat routines; they slow the execution exponentially.<BR>
<BR>
- The fewer the characters, the faster they compile; "num of flds" is quicker than "the number of background fields".<BR>
<BR>
- Preferences can be stored in a text file as well as fields.<BR>
<BR>
- Just because you can doesn't mean you should. Less is often more, especially with colour.<BR>
<BR>
- Try using modal windows rather than popup fields.<BR>
<BR>
- Back up regularly, and use version numbers. Three generations of work is better than two.<BR>
<BR>
- Differentiate between a comment line (note) and a commented line (disabled) eg<BR>
<BR>
## This is a note...<BR>
-- get myArray(n,t) ## now defunct <BR>
<BR>
... It helps debugging.<BR>
<BR>
/H<BR>
_________________________________________________<BR>
Hugh Senior<BR>
The Flexible Learning Company<BR>
Consultant Programming & Software Solutions<BR>
Fax/Voice: +44 (0)1483.27 87 27<BR>
Email: mailto:h@flexibleLearning.com<BR>
Web: www.flexibleLearning.com</FONT></HTML>