retrieving class

[John Robin Dove]

Hi Clifton,

Thanks for your help. I did what you suggested but the problem is still there. I am loading 3 HTML docs and 2 TB DHTMLs. Bearing in mind what you say I have tried eliminating each of these but the result is always the same. The TB files always load twice. I have tried loading the TB files first and the others afterwards but this has not worked either. For the moment I don't know what else to try. The other depressing thing is that the file is so full I regularly have trouble exporting it to DHTML. Surprisingly re-starting the computer usually allows me to continue but I can't see any TB files running in the Task Manager.

On the positive side I have come a long way very fast on another aspect of the program. My original translation database was in XLS format. I converted this to CSV via an online app and then from CSV to XML. With very little coding I have quite an impressive result. The database has 700 lines and 5 columns corresponding to 5 different languages. The translations arrive in a split second! Of course this probably means yet more loading via pgGotoURL unless I can combine it with another HTML. Anyway here's the result: http://www.mediacours.com/gettext It cheered me up a lot.

[Clifton]

Too bad that your files keep crashing when authoring/exporting.

Curious, are you regularly using the trim page memory feature in the PowerPac? This is is not that necessary for multiple-page projects where you are moving around a lot. In those cases, the page memory is trimmed automatically. However, in some of your projects, you seem to be creating complicated single page HTML documents. Page memory in older ToolBook versions can become stressed in these cases if you have a lot of objects and long action sequences. It may help to use the PowerPac menu option to ease the page memory footprint a little bit.

Memory trimming involves removing variable references that are not actually used by the object. Only those that are actually part of an action sequence of the object are retained, thus trimming the overall page memory usage. As you author a page, object references naturally fill up memory space again because of how ToolBook caches the references. So periodic trimming keeps the memory footprint from growing out of control.

Also, if you are using Windows 7 or 10, you can try using Oracle's VirualBox to run Windows XP in a virtual machine. Windows XP may play better with a large ToolBook project which is based on the v9.01 authoring files.

Keep in mind that you can read XML files into your ToolBook pages—(using PowerPac's XMLHttpRequest() function)—and have the cached data immediately accessible when retrieving language snippets. The PowerPac function is asynchronous so it will not interfere in any way with page loading and you can execute a callback or user event once an XML file has loaded its data. You can also offload some of your action code into XML files and save on some of your authoring load in ToolBook. (Please review the XML reference topics in this forum.)

Glad your project is heading in a forward direction!!

[John Robin Dove]

Thanks very much for all the useful advice and encouragement. It's been a frustrating day again. I started out using the trim page memory feature. I hadn't been using it and you're right my programs are usually just one page with a reasonable number of objects but stuffed full of code. After using this a new error message kept showing up:

It could be coincidental but I hadn't seen this message before. The real problem of course is the excessive quantity of code. If I could somehow reduce it, all the error messages would almost certainly go away. Does trim page memory have any advantages over saving the book with a different name? So far I have always been able to export to DHTML by 1) saving with a different name 2) using the repair kit 3) rebooting the computer. After resorting to one, two or all three solutions combined, I can continue working! I already use an XML file as much as possible to set up the page but I imagine that the XML can't include functions or global variables.

XP on Virtual Box would probably help but I don't have a suitable XP installation CD. I think the only conclusion is that as much of the code as possible MUST be offloaded otherwise this project will never be finished.

I have a new idea. Rather than offload to a js file which doesn't always seem to work (that could be due to my programming) maybe, thanks to pgExecuteRemote, I could store some in one of the secondary TB programs that I load with pgGotoURL. I have looked at some of my shared actions that could be dealt with in this way and I could certainly reduce the number of lines in each quite a lot.

My program uses an array to hold a lot of data. The contents would be a bit like this:

Code: Select all

12147,6,r1,3406,What animals can you see?
14241,4,3954,1,1
19687,3,r3,6125,Testing for recording without pause.
25970,4,6079,2,1
32881,7,Two natural predators in empathy.,6283,
39164,4,5500,3,1
43144,1,Here is a text being displayed without pausing the video.,20844,
63878,4,4688,4,1
77240,2,5000,,This is a text being displayed while the video is paused.
77240,4,5828,5,1
84804,6,r11,6172,Teacher recording followed by unlimited student recording.
84804,4,,6,
91590,3,r13,5312,Commentary without pause.
96969,4,,7,
100668,7,We're in the open. We're in the frontierage. It's not like we're in some civilized place.,6624,
107292,4,,8,
112462,1,So far¤ so good?,9447,
121909,4,,9,
125519,2,5000,,The End
125519,4,,10,

but in theory there could be 60 lines and each line could be considerably longer if the user wants to display a lot of text. Each line is in an array index. Is there any way I could make this array available to more than one TB DHTML. I vaguely remember you explaining something about user the browser local data storage but maybe this would not be relevant to this particular problem. Even if this is not possible I am pretty sure I can reduce the size of the current shared actions by performing some of them in a second book.

Another question: I know I can load my XML database using XMLHttpRequest() but how can I access it in TB? In the example I showed you the code that finds the appropriate translation snippet is in the html that I load into a field. Maybe I could use this code with exeJavascriptDirect?

Sorry to bother you with all this again. I really appreciate your help. I'm going on vacation soon so I''l leave you in peace for a while.

[Clifton]

It's been a frustrating day again. I started out using the trim page memory feature. I hadn't been using it and you're right my programs are usually just one page with a reasonable number of objects but stuffed full of code. After using this a new error message kept showing up:

It could be coincidental but I hadn't seen this message before. The real problem of course is the excessive quantity of code. If I could somehow reduce it, all the error messages would almost certainly go away. Does trim page memory have any advantages over saving the book with a different name? So far I have always been able to export to DHTML by 1) saving with a different name 2) using the repair kit 3) rebooting the computer. After resorting to one, two or all three solutions combined, I can continue working! I already use an XML file as much as possible to set up the page but I imagine that the XML can't include functions or global variables.

I fairly certain the error message is to a "boatload" of action script code. The PowerPac's memory trim feature only acts on unused object references. Each time an action is placed on an object, especially one using a PowerPac reference, ToolBook's behavior is to copy the entire PowerPac library to the user properties of that object. YIKES! This overloads a page quickly unless the number of object holding action code is reduced.

Another reason why your book is crashing so often is that actions are written out to openScript when the editor is closed. ToolBook has to add duplicate code to the object to support openScript native mode support for the object. Since there is a limit to how large a single script can grow, my guess is that you are exceeding the 32kb boundary and this is causing your book to become very unstable.

Also, if you write a lot of sharedActions, the code for these is stored at book level. So if you have a lot of these and they are complex, then the result is the book itself is overloaded with book level openScript. Even the latest ToolBook versions are not likely to handle the memory stress imposed here.

YOUR GOAD HERE should be to REDUCE your action code. Try and reduce the number of actions for any single event on an object to less than about 50.

———————————<< MOVING ON >>—————————————————————————————————————————————

XP on Virtual Box would probably help but I don't have a suitable XP installation CD. I think the only conclusion is that as much of the code as possible MUST be offloaded otherwise this project will never be finished.

Based on the above memory discussion, I do NOT think a virtual box would solve anything.

———————————<< MOVING ON >>—————————————————————————————————————————————

I have a new idea. Rather than offload to a js file which doesn't always seem to work (that could be due to my programming) maybe, thanks to pgExecuteRemote, I could store some in one of the secondary TB programs that I load with pgGotoURL. I have looked at some of my shared actions that could be dealt with in this way and I could certainly reduce the number of lines in each quite a lot.

Your likely solutions are to link your application to a MySQL database and use PHP to query the database for information when your application needs it. You can easily reduce your dependency on Action code by using PowerPac's XML engine to read in XML files with contain both data and executable code. When an XML file is read into a ToolBook DHTML app, the PowerPac automatically stores (caches) the data into and array. The key is to copy the contents of the array to your variables that the Action editor will understand. The XML part of this forum already contains this type of data handling, but I will post one that is more specific to your application later.

To execute code in your XML files, simply wrap the code sections inside <exeJavascriptdirect> . . . </exeJavascriptdirect> tags. Usually this is done in the config section of an XML file.

My opinion is that a combination of these techniques may be necessary to complete your application and to give your ToolBook authoring environment some breathing room.

———————————<< MOVING ON >>—————————————————————————————————————————————

My program uses an array to hold a lot of data. The contents would be a bit like this:

Code: Select all

12147,6,r1,3406,What animals can you see?
14241,4,3954,1,1
19687,3,r3,6125,Testing for recording without pause.
25970,4,6079,2,1
32881,7,Two natural predators in empathy.,6283,
39164,4,5500,3,1
43144,1,Here is a text being displayed without pausing the video.,20844,
63878,4,4688,4,1
77240,2,5000,,This is a text being displayed while the video is paused.
77240,4,5828,5,1
84804,6,r11,6172,Teacher recording followed by unlimited student recording.
84804,4,,6,
91590,3,r13,5312,Commentary without pause.
96969,4,,7,
100668,7,We're in the open. We're in the frontierage. It's not like we're in some civilized place.,6624,
107292,4,,8,
112462,1,So far¤ so good?,9447,
121909,4,,9,
125519,2,5000,,The End
125519,4,,10,

... in theory there could be 60 lines and each line could be considerably longer if the user wants to display a lot of text. Each line is in an array index. Is there any way I could make this array available to more than one TB DHTML. I vaguely remember you explaining something about user the browser local data storage but maybe this would not be relevant to this particular problem. Even if this is not possible I am pretty sure I can reduce the size of the current shared actions by performing some of them in a second book.

Another question: I know I can load my XML database using XMLHttpRequest() but how can I access it in TB? In the example I showed you the code that finds the appropriate translation snippet is in the html that I load into a field. Maybe I could use this code with exeJavascriptDirect?

The data you show could easily be put in an XML file. However, if the data must be dynamically altered, it would be better to use a MySQL database to store the specific data and have the XML file simply contain reference place holders (perhaps like > %1, %2, %3 . . . etc.) that are swapped for the real data when the application requests it. This would easily handle the fact that multiple translations of your application are being used. Of course, doing this is beyond what I can do in a free forum like this.

Nevertheless, I will update this post with a link to the XML section of this forum as that is likely the best place for future discussion of a topic like this. The topic will contain a basic working example of how to manipulate XML data read in from a file when a ToolBook page loads.

[John Robin Dove]

Thanks Clifton