PG Software Development

Hi Clifton,

Had a rather frustrating day yesterday with two problems I couldn't understand. It took me hours to find solutions.

The second problem was due to my superficial reading of the notes about htmlVideoLoader. When I first started converting my program from VB.NET to TB/Powerpac the results were acceptable but my programming structure was rambling and messy. I have since discovered shared actions and object methods and so I am currently doing some necessary tidying up. I think you have added some refinements to htmlVideoLoader. In my first program I guess the video was automatically reloaded when it reached the end so the currentTime property was reset to 0. In the latest version of htmlVideoLoader this is not the case. It took me a long time to understand what was happening: the currentTime property was still set to currentTime corresponding to the end of the video when the video restarted. This was a disaster for my system which relies on the currentTime value to carry out its tasks. I have now discovered that the loop parameter can be set to rewind or reload which solves the problem.

I have found a solution to the first problem but I still don't understand it. I use a text file to get data and instructions about what the program has to do. I get it from the server with XHTMLHttpRequest - no problem. The data is divided into textlines and items (Toolbook influence). I get the textlines by using pgSplitToArray with crlf as the splitExp parameter and I get the items using getItemFromStack. One of the textlines contains the length in milliseconds of the media file to be exploited. In this case the video was very short about 32 seconds: 32450 ms. When the video is loaded I display the 1/4 1/2 3/4 and full length in min:sec. As you advised I used pgDateFormat to achieve this. I put the 'textline' containing the length into a variable called medialength so the code was basically medialength * 0.25 => pgDateFormat => chars 4 to 8 of output etc. This worked fine for 1/4, 1/2 and 3/4 but the full length medialength => pgDateFormat produced 00:00:00. I tried all kinds of variations but nothing worked until in desperation I did mediaLength * 1 => pgDateFormat. This worked! I'm guessing that the data extracted by pgSplitToArray was somehow not a 'pure' number and the process of multiplying by 1 restored its 'purity'. Any ideas? I looked for pgTrim but didn't find it.

I have another question but I'll start another topic.

Regarding the currentTime property of your videos, this is likely due to recent versions of the VideoJS component. There have been some bugs and behaviors that the developers have been working to clarify and fix. One of them involved behavior that occurs at the end of a video. The developers of VideoJS are awesome programmers! PowerPac's htmlVideoLoader() manipulates the VideoJS component dynamically based on developer requirements.

Regarding pgSplitToArray():
It is important to understand that this function will split strings by strings. The result is an array of strings. So in your situation, if one of the textlines is a number, to JavaScript it is just a string made up of numbers. JavaScript is a pretty forgiving language and it tries to understand how you are using string numbers. If math is performed, the string number is converted to a number so the math does not result in concatenation.
Examples:

• In the case of "12" + 1 we would expect the result as 13 and not a concatenated string "121"
• However, "012" + 1 will probably result in "0121" but "012" * 1 + 1 will probably result in 13. This is because multiplication tends to force more reliable conversion than simple addition.

The problem comes in when working with pgDateFormat() which can take numbers and strings for its input. In this case, it explicitly examines the type of input to ensure predictable results.
Example:

The function can accept a date as a number OR it can accept the date as "01/10/2015". If the function did not explicitly handle this correctly, math would be performed on the input when the input in the second case is a real date string that must be converted to some other format.

Some of these issues also occur when working with boolean strings. The string "true" is not the same as setting a value to true. Case in point is if you use pgSplitToArray() on the string "true,false,true,true,false" and split by the comma (","). You are going to get several true/false values, but they are essentially just strings as far as JavaScript is concerned.

Conclusion:
Sometimes the PowerPac will try and interpret this to be forgiving, but it is best to be sure to input the correct value and type (whether string, number, or boolean).

Thanks for your detailed reply. This confirms what I thought was happening. How can you 'input the correct type'? The Toolbook actions interface doesn't seem to distinguish between different data types for variables apart from single variable and array.

pgSplitToArray() always converts input to a string and then performs its operation. You cannot split to an array a number because it is a numeric entity. So pgSplitToArray() will convert it to a string first and then perform the split, but the result will always be a collection (or array) of strings.

To convert:

• Numeric string to number, multiply the value by 1 in the Actions Editor.
  "25" * 1 will equal a number 25.
• To convert a number to a string, concatenate an empty string to it in the Actions Editor.
  25 & "" will equal a string value.
• To convert to boolean:
  set variable tmp to (tmp = "true")
  The above Action will check if tmp is the string "true" and return boolean true or false.

Thanks. So for string to number I stumbled upon the correct procedure!

I now have another problem concerning pgSplitToArray.

I have this string: 8948,4,,1,
item 0 = 8948
item 1 = 4
item 2 = ""
item 3 = 1
OK so far but
item 4 <> ""

So what is it?! In my VB.NET program item 4 is either Nothing or a number from 1 to 10

Nothing means the student can attempt to record an answer an unlimited number of times. A number limits the number of attempts.

I would like the system to be compatible with my VB.NET program and my TB/Powerpac version.

Maybe the item also contains the cr or crlf? How can I use it?

I have now found a workaround.

The problem textline (to use a Toolbook term) I had to deal with was "8948,4,,1,"

I needed to indentify the 5th item (item 4 because I'm using a zero based array). Incidentally I noticed that if the line was written like this "8948,4,,1" the 5th item was returned as 1 which is a bit disconcerting!

I then discovered that the textline (which had been created from a list of textlines by using pgSplitToArray: splitExp parameter = crlf) had an invisible unknown character at the end after the last comma. I still don't know for sure but I assume it must be an lf. Unfortunately I was unable to check this with a condition in the Toolbook actions interface because lf is not allowed only crlf is recognised.

My solution is to trim and rewrite each textline as soon as it has been created by pgSplitToArray. I get the charCount and if the last character is not a comma I redefine the textline as chars 1 to (charcount -1) of textline. I then add a comma at the end to ensure that the last item is read correctly. So the textline becomes "8948,4,,1,,"

So far this seems to be working ...

When I use your submitted string it behaves as expected, with the 5th item of the array (myArray[4] for zero based) is undefined. My guess is that the application generating the string is adding a linefeed, carriage return, or tab at the end of the string (some sort of white space). You can do a pgReplace() and get rid of all white space at the beginning and end of the string with a regular expression:

pgReplace() (parameters)

searchText = "/^\s+|\s+$/" (this is a JavaScript regular expression and the function supports their use)
replaceText = ""
theSource = [your comma separated string or variable]
replaceAll = true
ignoreCase = true

You can also use pgReplace() get rid of all multiple commas, but I think position in the array is important to your application so I wouldn't do that.

Hi Clifton
Thanks for your reply. Yes I think you're right. In the VB.NET version I use .trim to eliminate the unwanted end character so in this version I can use pgReplace in a similar fashion.

I think I have perhaps now discovered why my use of pgSplitToArray creates unwanted characters. I have made some test apps to examine this. My VB.NET app, which created the text file I am using in my program, saves the file with unicode encoding. This does not actually cause a problem for the VB.NET version when the file is read again. I use .trim for each 'textline' just in case but in fact this is unnecessary as no superfluous characters are produced when the text is split using crlf as delimiter.

Why would this happen in the Javascript version? Is it possible to specify encoding types in Javascript? If not, it's not really a problem as I can use pgReplace to trim the lines as you suggested.