On Jun 19, 2007, at 11:17 PM, Shari wrote:
The list is at <http://revolution.byu.edu/design/bestpractices.html>
I'm interested in anyone's thoughts about them.
Are they helpful?
Could some of them inadvertently cause problems down the road?
Have I left something important out?
on Thoughts
Name all objects: Absolutely! Even using an ID can come back and
bite you later. There are situations where even that can change.
For example, you inadvertently copy and object without realizing
it. You discover this later, and delete one of the two. If you
delete the one whose ID you used in a script, OOPS! I know there
are other cases where an ID would change.
Excellent point. And this happens quite a bit with beginning
students. How easy is it to inadvertently alt/option-drag an object?
Or Command/Control-C then Command/Control-V,V? (Oops! didn't realize
I hit paste twice!)
Another naming gotcha: Have you ever gotten an "object doesn't exist"
error, and you check the name and it looks exactly right and you
spend a long time trying to figure out why your handler can't see it?
This happened to me years ago in HyperCard, and I spent many hair-
pulling-out minutes trying to figure it out. I finally discovered
that I had put a space at the end of the button name in the button
inspector dialog. I deleted it and, presto! Button now exists!
Nowadays that's one of the first things I check in situations like this.
Comment your scripts: Agree again. Sometimes naming the handler
to match isn't enough, especially with a long script. One thing I
do with very long scripts with many if's and repeat loops nested,
is to comment the beginning and ending of an IF or REPEAT, in order
to match them up. I've got scripts where it's nearly impossible to
figure out which END goes with which beginning. And if you're
trying to troubleshoot, having things well labeled can be a lifesaver.
Agreed. I do something like this, too. I also comment 'else' clauses
with the condition that matches it, or a comment explaining what
conditions should trigger that clause, like this:
if fld "firstname" contains "Tom" then
# really long list of instructions
# and somewhere, scrolled out of sight is the...
else # firstname doesn't contain "Tom"
# do other stuff and never forget
# who this else belongs to
end if
Cross platform issues: There are many more issues than text and
colors. Option buttons appear so much differently that I had to
force one program to use a particular look and feel on every
platform. There were no button style choices that looked and
behaved as desired on all platforms. Preference locations and
permissions issues are vastly different. My Mac users almost never
bump into permissions issues, but my Windows users are constantly
encountering this, so I've had to change how I save anything on
Windows. So check your stack on several computers to make sure it
saves data properly to whatever text files, preference files, or
stacks you have with changing data. Creating desktop shortcuts is
also handled differently depending on the platform. Too many
differences to recall at 1 a.m. :-)
Another cross platform issue: Consider the screen size, and how
the menus will vary from platform to platform in relation to
affecting your available screen real estate. So choose a stack
size accordingly. Remember that Macs will have not only a Mac
menubar, but the dock as well, affecting your available territory.
If you want your stack to completely fill the screen, don't use a
menubar, use buttons in the stack window.
BIGGEST cross platform issue: Don't hard code your file paths for
preference file locations! If you do, they might work today, but
tomorrow they will break, guaranteed. How many folks ever
hardcoded the path to C/Program Files or something similar? With
all the Windows permissions issues, as well as issues for other
countries systems being slightly different, always use Rev's built
in specialFolderPath().
Thanks for these ideas. I spend a day on building standalones and
cross-platform issues, so I will include some of these considerations.
Regards,
Devin
Devin Asay
Humanities Technology and Research Support Center
Brigham Young University
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
