Behaviors and Custom Controls

Behavior Helper Plugin

http://www.bluemangolearning.com/download/revolution/tools/BehaviorHelper.rev.zip

Custom Control Helper Plugin

http://www.bluemangolearning.com/download/revolution/tools/CustomControlHelper.rev.zip

Behaviors & Custom Controls Stacks

http://www.bluemangolearning.com/download/revolution/tools/behaviors_customcontrols.zip

Instructions Showing How To Install a Plugin

http://revolution.screenstepslive.com/spaces/revolution/manuals/plugins/lessons/5489-Installing-the-Plugin

Password Font

http://www.bluemangolearning.com/download/revolution/tutorials/passwordentry.zip

Presenting Data with the Data Grid

Data Grid Sample MP3 Library

http://www.bluemangolearning.com/download/revolution/tools/data_grid_sample_mp3_library.zip

Creating a Music Library Interface Part I

http://revolution.screenstepslive.com/spaces/public_staging/manuals/740

Google search field in Safari

Placeholder text can be very useful as it provides a visual queue to the user about what the field does while not requiring any extra space in your UI.

Using custom properties and behaviors (new in Revolution 3.5) you can easily add this feature to fields in your applications. See the lesson How To Create Field Placeholder Text Using Behaviors.

I considered 4 possible approaches.

1) Handlers That Return Valid Data or Errors

If you have ever used one of the Revolution externals such as revDB or revXML then you are familiar with this technique. The handlers in these externals can return valid data or a string that starts with revdberr, or revxmlerr,. This is what a WordPress library handler might look like using this method:

put wp_getCategories(pParamsA) into theData
if theData begins with "wperr," then
   // item 2 to -1 of theData contains an error
else
   // theData contains valid data
end if

2) Function That Returns Last Error Generated By Library

When working with libraries another option is to have the library log any errors internally and then have a function that returns the last error generated by the library. This is what a WordPress library handler might look like using this method:

put wp_getCategories(pParamsA) into theData
put wp_lastError() into theError
if theError is not empty then
   // Something bad happened
else
   // Do something with theData
end if

3) Throw Errors
Another option is to throw any errors that occur within one of the library handlers. This requires wrapping any calls to the library handlers in try/catch statements.

try
   put wp_getCategories(pParamsA) into theData
catch theError
end try

if theError is not empty then
   // Something bad happened
else
   // theData contains valid data
end if

4) Place Errors in the result and Return Data In it

This is the approach that the Revolution engine uses in many cases. For example, if you use the post command any errors are reported in the result and the data returned from the web server is placed in the it variable. Likewise, this is how a command like decrypt behaves. This is what a WordPress library handler might look like using this method:

wp_getCategories pParamsA
put the result into theError

if theError is empty then
   // 'it' contains data returned from the server
else
   // Something bad happened
end if

I’ve never liked option (1) as I don’t think that mixing error reporting and results is a good idea. What if the actual value started with your error string? Likely? No. Possible? Yes.

Option (2) would probably work fine as I don’t think you would get invalid results if you had multiple calls to the library going on with send in time calls (I could be wrong but I didn’t go with this approach so I didn’t test it). I just don’t care for that sort of API.

Option (3) requires too many lines of extra code for my taste and it doesn’t seem appropriate to throw an error if communication with the web server fails for some reason. Throwing errors should be reserved for circumstances where the developer has passed in bad data that he should have cleansed ahead of time.

That left me with option (4) and this is the option I ended up using. The reason I like option (4) is that this is how the engine behaves in a number of places. Errors and data are clearly separated and I like using a “native” approach as calls to my library handlers will read the same as calls to engine handlers.

There was only one problem left. How could I set the it variable in a command? Revolution only supports setting the result from a command. It turns out that you can set variables in calling handlers by using the debugContext so I whipped up a little handler called SetValueOfItInCaller that did just what I needed. Take a look at the Write a Command That Sets ‘the result’ And ‘it’ lesson to see the solution.

Most developers are familiar with using

go [invisible] stack "/path/to/stack"

to load a stack file into memory. But ‘go stack’ actually opens the stack on screen and triggers the [pre]openStack and [pre]openCard messages. You don’t want either to happen if you are just validating stack file existence and loading into memory. Although you can hide the stack and lock messages there is a way that requires less lines of code.

The best way to verify that a stack file exists on disk and load it into memory without triggering any messages or showing it on screen is to do this:

put there is a stack "/path/to/stack" into theStackFileIsLoaded

By checking for the existence of the stack file on disk, Revolution will load the stack into memory. if theStackFileIsLoaded = false then you know the stack file doesn’t exist.

On a somewhat related note check out the Knowing Which Stacks Are In Memory lesson. It has a function that lists all stacks that are currently loaded in memory.

Given the extremely positive response by attendees, Greg and I thought people might be interested in seeing how ScreenSteps 2.5 uses data grids throughout the application. So we’ve added a new webinar to our webinars page entitled Using Data Grids in Revolution 3.5. In the webinar we will show you:

• The various UI elements created using the data grid.
• The techniques used to create some of the visuals.
• The techniques used to hook the data grids up to data from SQLite, stacks, folder contents and the web.

We also plan on providing ample time to answer questions people might have. So join us on Thursday April 30th if you want to improve your data grid chops.

Sign up for webinar

Update: The webinar video has been posted in our archive.