Rev Mentor

Tips, tricks, news & commentary for Revolution developers

New Combo Box

Watch me walk through the functionality of and code for a new type of combo box we are creating for a client:

(download)

Here is the Revolution stack shown in the video:

Click here to download:
new combo.rev (19 KB)

NOTE: this is a beta version, there may be bugs! Act accordingly if you choose to use this code.

Enjoy!

Skype: jerry.daniels

Get the parent group of a control

By being binary (staying within the Rev engine as much as possible) you can extract the parent group of any object with just a few lines of code and NO repeat loops or complicated, incrementing offset functions.

Here's what you need to do:

  1. First get the long name of the object.
  2. Put all references to a group within the long name on a separate line.
  3. Replace " of group " with a return and "group " to do this.
  4. Filter out all lines but the ones starting with "group ".
  5. If, after the filtering, there are still lines, then you have a parent group.
  6. The last line is the "parent" of the object, otherwise, it has none.
That'll do it.

 

Nesting is for the birds

Get the Flash Playerto see this player.
(download)

I'd recommend this script...

put the id of this cd into theCdID
put getSelectedImages(theCdID) into theImageNames
put getMyImageIDs(theImageNames) into theImageIDs

...over this script...

put getMyImageIDs(getSelectedImages(the id of this cd)) into \
theImageIDs

...any day of the week.

My recommended script — though more verbose — is nevertheless the kind of code that builds the value of your app as an ongoing asset for four reasons:

  1. Although nesting functions within functions (as in my non-recommended script) does eliminate the use of two variables — it also keeps you from checking the values in those variables in a debugger. So, for the sake of debugging, the no-nest policy is invaluable.
  2. During a code audit, the verbose, self-documenting code always yields a bigger (read more impressive) number of total lines.
  3. You'll be better able to understand your own previously-written code when you return to it (cold) weeks or months or years later.
  4. Implemetation of these recommended coding standards increases your code's (or even your company's) value to a third party by significantly reducing the time and effort required for new coders to "get a handle on" your existing code.

You may be wondering, however, if verbose code runs slower. The answer is: not to any degree that a user would ever notice or measure. How about in a lab? Repeat loops may run some millisecs slower, but, the gains are well-worth such a teeny trade-off.

Scripting - it all starts with a name

Get the Flash Playerto see this player.
(download)

The first step to writing great Revolution scripts is often relegated to after-thought. I'm referring here to the naming of things. What's the big deal?

The true value of your code is determined more by an endless series of small naming decisions than any other single act.


NAME IT WHAT IT IS

I strongly recommend naming a thing exactly what it is--based on what it does or has done to it. That means using "it" repeatedly in a script would be verboten. Why? Because "it" tells us absolutely nothing about the data to which it points. 

The same principle applies to using "x" or "i" as an index variable in a repeat loop. What does the var "i" tell you?

repeat with i = 1 to n
   put i && the date into line i of fld 1
end repeat

Wouldn't the following tell you more:

repeat with theLineNo = 1 to theNoLines
   put theLineNo && the date into line theLineNo of \
      fld "list of dates"
end repeat

This makes your code self-documenting and much easier for you and your antecedents to read. It also establishes a higher market value for your code, app or company, provided you follow your own standards consistently.

 

NAMING A VARIABLE

When Dan Winkler invented HyperTalk (the basis for Revolution's scripting language) he would call a variable that contained the today's date the following: theDateToday. He would not have used tDate.

Scripters started prefixing vars with single char abbreviations to indicate what type of var they represented: t = temporary; g = global; l = local; a = array; k = constant. A worthy goal and I agree with much of it, actually--just not the business with temp vars. Using "the" as a prefix makes the code more readable, IMO.

My rationale goes as follows: gratuitous use of single character pre or postfixes serve to make the scripting language more codified and cryptic than it needs to be. I suggest using only as much mumbo-jumbo as absolutely necessary. Prefixing a global with a "g" makes sense, if you think you need to use globals, that is.

Some folks name the parameters of a function, command or system message handler with a lower case "p" preceding them. Why? No one can answer this. "So I can tell if it's a parameter." What difference would that make if it was a param? None. It's decoder ring stuff. The priesthood. Ignore its call to your nescient adolescent ego. You've probably got a wife and kid. What do you have to prove?

Since Revolution eliminates the need for data typing, I see no need to include the type of data to which a var points. I wouldn't use "available_boole", but I would use "isAvailable" because it reads very nicely in an "if" statement like this:

if isAvailable then
   doReorder
end if

I think you can see where I'm going with whole line of reasoning. Proper naming can not only create readable code, but it makes for maintainable, saleable code.

 

NAMING A HANDLER

Why not name a custom handler with the same criteria in mind? Keep in mind how the name of a handler will look as you call it from another script.

This handler...

function todaysDate
   return the date
end todaysDate

...will look like this when you call it:

 

put todaysDate() into theDate

function stockIsAvailable
   put the number of lines in fld "stock" is not empty \
      into haveStock
   return haveStock
end stockIsAvailable

Name a variable or handler properly, and it works for you. Otherwise, you end up working for it.

Application lifecycle video

Get the Flash Playerto see this player.
(download)

As a product publisher or project manager, you oversee three basic activities:

  1. Design
  2. Develop
  3. Deploy

Design is a process that iterates between vision and prototype until you feel the design will be well accepted by its end-users. Development iterates between building and testing until the level of bugs is low enough to deploy the app to the end users. Design begets a prototype; development begets an executable; deployment begets a group of users.

A more detailed view of the lifecycle:

  1. Design
    • (Re)Vision
    • Prototype
  2. Develop the prototype
    • Build
    • Test
  3. Deploy the executable
    • Announce
    • Document
    • Train

This whole process iterates throught versions of the app which follow a product or project roadmap. Pretty simple, but once engaged in the minutiae, it's very easy to lose your way. As a publisher or manager, its your job to keep the faith and keep your eye on the spitball — which is what this cycle looks like if you squint at the diagram shown above.