Case Study: Creating a Customized Display of Results Function

December 12, 2003
by Jason MacDonald

The more than 12,000 independent scientists who attended this year's Experimental Biology meeting in San Diego, California (April 11-15), were given the option of carrying around a lightweight CD-ROM instead of two bulky volumes in order to reference the meeting's thousands of abstracts. The six societies participating in this year's annual meeting decided it was time to lighten the load of its members by contracting us to create a customized abstract search and itinerary-building CD-ROM to complement the two hard-copy volumes containing the same information.

"The major advantage of a CD-ROM over a hard copy of the abstracts and meeting information for the user is that because the CD is searchable and generates a personal itinerary, the user only needs to print out the abstract for the meeting they wish to attend. He or she doesn't have to travel with the heavy abstract volumes or carry them around to the sessions he or she attends," says FASEB's Nancy Rodnan, Director, Office of Publications.

Not light on content

From the time we received the CD-ROM specifications January 2003, it took us only four weeks to build a complete turnkey solution using Macromedia¨ Director¨. Behind the scenes, a database stores 8,405 unique records containing detailed information about all the available sessions at the meeting and 6,497 abstracts saved as PDF documents. Along with the database and PDF documents, we also included a custom-generated HTML itinerary, our own graphics and a custom installer. The CD-ROM allows the user to perform a Boolean search not only on the abstracts but also on 10 different session types (courses, lectures, symposia, etc.), seven scientific societies, as well as authors, locations and other criteria. Users click the abstract link, decide whether or not it interests them and then add it to their personal itinerary with another click. Once the itinerary is complete, they can save the list and print it out if they wish.

In this application, using a database is absolutely necessary in order to properly manage the content. A database allows for quick, easy and accurate retrieval of information while keeping files sizes small and memory usage efficient.

Getting results

As it is impossible to load 8,405 records at once during a call by the user to search the database, we had to create an expandable and reusable function for displaying large of amounts of information. Although Director does allow for customized display of results, we required a table that would allow us to control the properties of each Column and Row, thereby ensuring that the table would always display a maximum of three records per page, regardless of the amount of data called up by the user. In other words, we needed a customized table that would not automatically expand or contract the fields within itself to conform to the amount of data retrieved.

To do this, we created a "faux" table that includes text cast members (in effect, placeholders) and a function or routine to populate these members with information from the database, such as Title, Author, Session, Date, etc. With a click of a button, the text cast member essentially instructs itself to search the database looking for sprites (references) that point back to the cast member, thereby retrieving the data required. It does so via the following naming convention, using "displayCursor,searchIndividuals,sessionTitle,1" as an example:

• "displayCursor" indicates that a display of information is required.
• "searchIndividuals" identifies what selection of the database will be used when populating this cast member.
• "sessionTitle" contains the field in the database that will be populated into the cast member.
• "1" is the record on the screen (with a possibility of 1, 2 or 3 only), or in other words which row on the stage it will be displayed in (see screen shot).

In the main engine of the CD-ROM, there are three casts: one for code, one for graphics and an internal cast with various items including the fields for displaying results. The "code" cast includes 26 cast members, the "graphics" cast includes 72 cast members and the "internal" cast includes 188 cast members, with each cast member having a unique name and a unique search requirement.

What makes this display function expandable is the ability to add an unlimited number of cast members to the function, while reusability is achieved through modification of the cast member versus the code itself. The code only has to be written once, as it is the cast member name (not the code) that contains the data retrieval instructions. Therefore, if new instructions or criteria are introduced, or the present criteria need to be modified, only the name of the cast member has to be changed - not the code.

Click for large screenshot of Stage and Score

-- ###############################################
-- # displayCursor
-- #
-- # Populates a row of data to the user interface
-- #
-- # Parameters:
-- # theCursorName: The name of the table that contains the selection to display
-- # theCursorPosition: The nth record to be displayed in the selection
-- # theRowNDX: The position on screen for the row to be displayed
-- #
-- # ( e.g.: displayCursor("searchIndividuals", 593, 1).
-- ###############################################

on displayCursor( theCursorName, theCursorPosition, theRowNDX )

  -- retreive the cursor reference
  lCursorRef = getCursorReference( theCursorName )

  -- move to the right position within the selection
  goToRecord( lCursorRef, theCursorPosition )

  -- Loop through all Sprite on stage
  lspriteCount = the lastChannel
  repeat with i = 1 to lspriteCount
    theMember = Member(sprite(i).member)
    
    if String(theMember) = "(member 0 of castLib 0)" then -- There is no sprite in this channel
      next repeat
    end if
    
    if ( theMember.name.item[1] = "displayCursor" ) then
      
      if (( theMember.type = #text ) and ( theMember.name.item[2] = theCursorName ) and /
         ( theMember.name.item[4] = string(theRowNDX) )) then
        
        -- retreive the data from the database field
        lFieldName = theMember.name.item[3]
        theMember.text = string( getField( lCursorRef, lFieldName ) )
        
      end if
    end if
  end repeat
end displayCursor

Scroll bars

In implementing this customized display function, we required a way for users to scroll through the retrieved records. As the scroll bar function included in Director can only be associated with one text cast member at a time, we needed to create a scroll bar that could be associated with approximately 30 text cast members at the same time. To give the illusion of seamless scrolling through the retrieved records, as opposed to having the user close and open windows to view the pages of information, we created a button scroll bar that when clicked calls a function (eg. "displayCursor") to repopulate the screen dynamically.

Why use Director?

A four-week turnaround would not have been possible without Director. Its excellent debugging environment saves valuable time, as does its smooth integration of our own user interface and software, as well as its acceptance of all major types of media.

As well, it is much more cost-effective thanks to the shorter timeline it provides, even with only a couple of people working on the project, as in our case. Director's cross-platform capabilities were also a huge asset in appeasing the broad range of users.

The great thing I find about using Director to build a project such as this is that although you only develop once, you can insert new content repeatedly. Projects can easily be updated with new data, cutting down preparation time even more on future versions.

Copyright 1997-2024, Director Online. Article content copyright by respective authors.