Consider your code as represented this way: var txt = "textA", button1 = "textB", button2, objName;
showRequest( txt, button1, button2, objName );
In the Actions Editor:The ToolBook actions system automatically assigns empty strings "" to any variable that is undefined. This is contrary to how JavaScript works, but causes everything to work in a predictable way for ToolBook developers at the Actions level. Therefore, showRequest() will receive your variables from the Actions system this way:
- txt = "textA"
- button1 = "textB"
- button2 = ""
- objName = ""
In JavaScript:tbfunction_showRequest( txt,
button1,
button2,
objName ) will send the variables EXACTLY as they are typecast or defined . . . so they are sent this way:
- txt = "textA"
- button1 = "textB"
- button2 = null (at javascript level) or "undefined" (Actions system interpreted)
- objName = null or "undefined" (see above)
This is not a PowerPac issue and never has been. Rather it is a logistic issue between the way each interface is typecasting the variables. The key on your end to make sure everything is typecast in a predictable way regardless of whether the variables are sent from the Actions system or from JavaScript.
SOLUTION:Adjust your function
showRequest2() to make things predictable.
Like this:
function showRequest2( [yourParams] ) {
var txt, button1, button2, objName;
.... do some stuff ....
//Now send the vars to the Actions interface so any undefined var has a default string type value
tbfunction_showRequest( txt || "", button1 || "", button2 || "", objName || "" );
}
In a way, you are right in that this is a lot like the bug problem with
snapObjectToCenter() where the align parameter was received as null from your function call to from JavaScript directly to the PowerPac without using the Actions system. My fix was simply to make sure the
align parameter was converted to a predictable default if null or undefined is sent from a native JavaScript call or XML file. This way the function will succeed every time.
BTW: You do not have to expressly send a catenated string separated by "§". Things can get clunkly and overly complicated. Try this instead from your JavaScript function:
tbfunction_pgTBObjSet( [tbName], "user", [ txt, button1, button2 || "", objName || "" ] );
Notice, I've defined an array to hold our separate variables that are sent to [tbName] as the [value] parameter. On the Actions Editor side [value] will be an array where:
- value[0] = whatever you set for [txt]
- value[1] = whatever you set for [button1]
- value[2] = the value of [button2] or an empty string ""
- value[3] = the value of [objName] or an empty string ""
This is a much cleaner way to handle sending lots of data around. Strings like you are using is really best left for sending short pieces of data.
I think you will find that most of the anomalies you are running into will be related to how variables are being passed around and defined. You can imagine the immense complexity that exists keeping things predictable between JS, Actions Code, XML, and PowerPac functions. And all things considered, users see VERY few error messages when working with the PowerPac and ToolBook. Sometimes if a function fails, it is because the PowerPac assumed a default that the developer did not expect. No error pops up because the functions fails gracefully behind the scenes because the way it was executed was still legitimate; just not as expected by the end user.