PG Software Development

This is a real problem for ToolBook developers. It would seem like the problem is a faulty authoring tool, but as you will see, this is NOT the case.

WHY THIS HAPPENS?
It is important to understand the limits that the ToolBook authoring environment imposes.

1. You cannot have more than 32k of code assigned to any one object.
2. The 32k code limitation is a combination of Action code and openScript.
3. Everytime your add an Action to your book, the authoring system has to duplicate the Action by automatically adding openScript code to the same object on which the Action code is placed.
4. Therefore, several long Action sequences can quickly fill up your resource limit in ToolBook and make the book unstable, or make it impossible to export successfully.
5. If you have lots of objects on the page each with Action code attached, the instability of the book will increase.
6. The use of many UMP (media play) objects can bring down your project. The PowerPac media players offer a more robust alternative and do not involve anything but a single line of action code.

Once the resource limit is reached, the book crashes at random times, places, and with few messages that make any sense to the author.

Solutions

1. REMOVE all instances of the UMP. It doesn't even work reliably in all modern browsers anyway. Instead, use PowerPac's media players for both sound and video.
2. Optimize your Action code by using fewer lines to accomplish the same task.
3. Spread out your Actions on several objects rather than on just the page, or background.
4. Consider using XML files to offload your code to objects that get dynamically loaded outside of the ToolBook authoring environment. You can still fire clicks, triggers, or user events. And you can still be notified by XML objects when data is handled. Objects created by the PowerPac's XML Parser are not restricted by size, etc. XML created objects in ToolBook improve the performance and speed of the export of your book.
5. Please examine the topics in the XML section of this forum for more information and examples.

Example of book using XML created objects using PowerPac's XML Parser along with the <make> tag:
http://www.pgsoftwaretools.com/powerpac/assessments/xml_forumpost/index.html

The above example only needed a single line of Action code for the on load page event to load the XML file using XMLHttpRequest(). You can study the XML file to understand how this works. I've included a copy of it below. Notice the file instructs ToolBook to execute code and PowerPac functions when it loads AND it provides for functions, or methods, of objects so ToolBook can execute portions of the code where necessary. I've commented the XML to clarify the purpose of each section.
(NOTE: Some features in this XML file require PowerPac v13.x or greater for support.)

Hi Clifton,

Many thanks for this. I'm working on it.

John

Hi Clifton,

I am seeing things in my published books that this might explain. Occasionally some objects on a page or background do not appear to load, and if these include buttons or controls that are required to navigate the page then the reader is stuck. Because I could not find a way to transmit SCORM suspend data at intermediate points in the book, the reader is forced to start over at the beginning. This behavior is intermittent but the occurrences seem to cluster together. I was thinking maybe the cause was interference in a wireless LAN but your explanation makes more sense.

Is there a way I can determine how much code is in an object, so I know if it exceeds the 32k limit? I ask this because many of my objects have lots of code, so I'd want to identify the most likely offenders. Also, is there a way to look at an incompletely-loaded page in order to determine if in fact this is the cause?

Thanks, Andy

If an object exceeds the 32k limit then it probably will throw an error on export and the export will not finish. It is unlikely that and an object will fail to load if the server is up and not bound by too much traffic when the request is made for page information.

To explore whether a server issue or a ToolBook export problem exists, try and put your export/content on a local server like XAMPP and test it there. If you cannot get it to fail at that level, then quite likely you have a web server issue.

Partial page loads can also be on the client side with ISP's and routers not delivering data properly. Especially when your have these problems intermittently I would tend to look a the way the content is being served rather than at the content itself. Generally, ToolBook exports just work, but they have to rely on web services to get all the data to the client browser. When some of the objects and other data do not get fully served, then pages will not work right and may even freeze the browser.

Things that lighten page load:

1. Avoid large file size graphics. Optimize them for the web and avoid like a passion using BMP images which for years was a default file type for ToolBook. Instead use png (preferred), or jpg. Reduce their file size instead of assuming the container will do that for you.
    
2. Avoid putting more than 30 actions on an object. This only makes the export take longer and sometimes it can make the Actions Editor unstable.
    
3. Learn to write your actions as XML files. This makes page loading very fast, especially if your web server uses gzip compression. If not then the PowerPac will gzip your XML files—but you will need to configure your web server to serve the gzip versions of your files. (See the online PowerPac API for information on setting up an .htaccess file to tell the server how to grab gzip versions of files.)
    
4. Instead of sharedActions, write XML functions that are attached to level 0 elements that you create using the <make> tag. This can really lighten the load time of your book and save a lot in export time as well. Consider this example:
   

   <make id="sharedActions" level="0" type="div" dims="-10,-10,1,1">
         <function name="myCalc" event="" params="val1,val2">
               <![CDATA[
                     /* CLIFTON: Calculate the product of two numbers.
                     ***/
                    val1 = pgIsNumber( val1, "num" ); //Verify numeric value using internal PowerPac function
                    val2 = pgIsNumber( val2, "num" );
                    return val1 * val2;
               ]]>
         </function>
   </make>

   
   
   Of course you can add as many function tags as needed to handle all your sharedActions. You simply attach them all to the same <make> object.
   Then, you call them using pgTBObjSet() like this:
   

   var result = tbfunction_pgTBObjSet( "sharedActions", "myCalc", [ 32, 465 ] );
   //result now will equal the product of 32 * 465 or 14880

   
   
   You can call XML-based functions from within an XML file OR you can call them from within the Actions Editor.
    
5. Avoid using too many backgrounds in your book. Generally, 1-3 backgrounds should be all that is needed unless you have some additional ones for dialog boxes. The reason for this is that the background objects will get served once for successive page loads that use the same background, so if something doesn't load right you are stuck. Page-level objects get refreshed on each page visit. This tends to provide a smoother transition, especially if you use the PowerPac's page transition feature.
    
6. Avoid styling text in fields at author level. Instead use a little CSS (stylesheet) and attach classes (which contain the formatting) to your field objects.
    
7. If your server doesn't like streaming video, then consider putting the videos on a service like YouTube and stream them from there. The PowerPac htmlVideoLoader() is equipped to handle YouTube streams.

There is much to consider here, but it shows the incredible flexibility that ToolBook now offers via the PowerPac. Developers should never be limited in what they should be able to do with their projects.
Of course, I am always available to assist you in getting your actual code to work in an XML environment from which you can grow into unlimited areas.

Hi Clifton, thanks so much for some helpful ideas. I had followed up on the script size issue and chose a page that had failed to load completely. Most of the actions were in the page itself, so assuming this script is correct:

local a[]
c = 0
o = this page
ee = asym_ea_handledevents of o
while ee <> ""
pop ee into e
a = asym_ea_actionarray(e)
step i from 1 to dimensions(a)
c = c + charcount(a[i])
end step
end while
request c

I was not even close to the limit. I will continue by investigating ways to lighten the load for each page, and you have provided many ideas on how to do this. Thanks again, Andy

Hi Clifton, I reviewed my books per your recommendations and for the most part they follow your guidelines. The largest html file for a page is around 50KB and for a background is 40KB. Javascript files are no more than 15KB. I do have a lot of shared actions, however, so maybe XML functions can help.

It turns out that every instance of an error has been on a wireless LAN. In one recent example, the pgsound scripts ran just fine while on the same page some toolbook-defined drag objects wouldn't move. So a partial load that missed the page's javascript file must have been the culprit.

This is my first project with toolbook actions and I didn't expect this. I thought that the published DHTML would have detected and corrected such problems. I understand that reducing page size using XML functions or other methods will help, but it seems like the possibility can't be eliminated. Is there something in the XML functions or other areas of powerpac that could be used to detect missing objects?

Thanks, Andy

If you can zip up a small sample (tbk + dependencies) of what you are having trouble with, I will examine it.

Send to [email protected]

Thanks! I will do that shortly.