PG Software Development

I am frequently interrupted by an error message which includes "An internal error has occurred in file unknown line 189." The result is always the same: Toolbook ends up being shut down. It could be worse, I suppose, because so far that is all that happens. The file can be opened again and does not appear to be corrupted. But it is exasperating! Apparently this is not a new problem. I found this:

http://bit.listserv.toolb-l.narkive.com/yjIZ4ZVJ/executing-a-database-update-from-within-toolbook

I am using 9.01. Perhaps this bug was dealt with in later versions. If not if anybody can offer any advice ... I think it happens when the pages are 'overloaded'. I only have 2 pages in my project but one of them is pretty full. I'm a bit apprehensive because I still have a lot more stuff to add to this page.

I would recommend running the book the repair utility to clean things up a bit and see if the repaired book if more immune to crashes. Also, when a book has so few pages, you may need to regularly execute the PowerPac menu item to "Trim page memory now ..." This process is automatic on page navigation which is fine in the vast majority of cases, but in your case you may need to manually clear the page memory footprint every so often.

What does the memory trim do?

The command will examine all objects on the page and remove references to PowerPac functions that are not being used. These references gradually fill up again as you build actions using the Actions Editor, but the memory trim operation can keep things a bit more manageable for ToolBook.

Hi Clifton,

I have followed your advice but the crashes keep coming sometimes immediately after a repair + memory trim. I hope to continue the project by adding separate parts with pgGotoURL() as you suggested but there are still a lot of things to include which must all be on the same page. I have started putting objects on the background but this doesn't seem to make any difference. If it's like this with only 2 pages what'll happen if I add more? I may have to create separate apps for the other pages but this would complicate things. Normally the project would have 5 or 6 pages. I've already spent well over a year on this conversion. I hope I haven't been wasting my time!

Crashes can cause corruption even if the book opens.

ToolBook has limitations to how much you can put on a single page and background and this includes your actions, etc. Having said that, what really matter most is when your actions sequences start to get very long (> 50 lines or actions that take a few seconds to load in the editor). It makes things work really smooth to put spread them out to sharedActions and on different events and objects. But if you put too much on a single object, it just makes things unstable ... at least in ToolBook v9.01. Later ToolBook versions seem to be a little more resilient.

Another thing you might consider is using the XMLHttpRequest() function to configure some of your page elements using an XML file. This would be loaded entirely separate from ToolBook authoring mode. Unfortunately, I don't have a lot of documentation on how to do this. However, our PowerPac Help API is mostly comprised of simple books with XML data files loaded at runtime. We've built the XML loader to handle pretty much any type of complex formatting and most PowerPac functions can be called directly from an XML file.

Thanks for your reply. Your last paragraph sounds promising but I have to admit I don't really understand what you mean. I discovered quite quickly that you can't use too many lines in the actions editor so I have always used shared actions and object methods as much as possible.

How could I configure objects using xml? There is very little text to display in my app other than button captions and a few textboxes. The problem seems to be the quantity of programming required and it isn't even finished yet!

There is one other thing I must try: running the Toolbook software on XP instead of Windows 8 but I'm not convinced that this will work because the line 189 error was reported as occuring on XP as well.

Basically, anything that configures the page can be off-loaded to XML.

• object styling
• triggers
• user events with values
• html tagging
• setting states like button enable/disable and content of any fields
• language translations
• anything involving exeJavascriptDirect()
• can even execute function AFTER a page has loaded, but this requires more of a custom XML setup which you can design yourself and then read in the actions using XMLHttpRequest(). I don this with a list of audio files with each one using a predefined custom volume setting.
• XML pretty much makes things unlimited in scope and off loads a lot of stuff into simple text files. Makes editing a little easier, but you really need to make a lot of comments in the files to make sure you don't forget what and why you set something up as you did.

Another approach is begin writing your own JavaScripts to replace some of your actions. This off loads sharedActions and other long actions into single line JS calls.

Of course all of this increases the need to learn a couple of other we languages. But it seems like you have done pretty well at this so far. If you want I can try and package up a couple of XML files used in the PowerPac Help API to get you started. I would only start doing this in a dummy book until you get the feel of how it works. Also install a good XML editor like SynWrite (my favorite) or NotePad++ (okay). PSPad, while okay too is not the best for XML writing, at least in my opinion.

Thanks Clifton,

I'm still a bit dubious but maybe if I saw some examples things would be clearer. So if you have time, yes please.

I think I'll start a new topic and post an actual working sample. May not get to this until sometime later today or tomorrow.

OK. Thanks. No rush as far as I'm concerned.