How to get AFExecuteThisScript to return value from Net.HTTP.request (asynchronous?)
i have acrobat-only plug-in, developed in vs 2005. acrobat 7 sdk, updated use acrobat 9 sdk. end goal of function open pdf file agile web server: given user string, url created, request sent url, receive response. response can either pdf file itself, or string path pdf file. thought easier use pdf path version, open new pdf http:// address.
i've created folder level javascript file trusted net.http.request call. have script works when called menu item added folder level javascript file. when using same command in c++ code afexecutethisscript, cant http response finish while waiting in code result.
asynchronous net.http.request , callbacks confuse me, may big issue. couldn't net.http.request return value in single javascript function, right i'm trying use 'global' variable in folder level javascript, , 2 calls. first call 'sets' global variable, second 1 'gets' it. seems issue. when debug code, or halt execution, response portion of net.http.request never called. when let go on beyond step error trapping, response appear.
so how kick off net.http.request , notified when it's finished? either in javascript or vc++??
any , appreciated. if better option stream file web server local file, , open (this option take in different tool runs outside of acrobat).
here's code.
folder-level javascript commands (urls truncated post)
var the_path = ''; function setthe_path ( gurl ) { console.println('setthe_path begin'); var params = { cverb: 'get', curl: gurl, ohandler: { response: function( msg, uri, e) { console.println('response method: setting path'); the_path = soap.stringfromstream( msg ); console.println('<<' + the_path + '>>'); } } }; console.println('url: ' + params.curl + '\n ohandler: ' + params.ohandler ); console.println('path: ' + the_path ); var netresult = trustednethttprequest(params); console.println('setthe_path end'); return the_path; }; trustednethttprequest = app.trustedfunction( function ( params ) { console.println('trustednethttprequest begin'); app.beginpriv(); var netresult = net.http.request( params ); app.endpriv(); console.println('trustednethttprequest end'); return netresult; } );
menuitems added folder-level javascript
app.addmenuitem( { cname: "mysetthe_path", cuser: "set the_path", cparent: "tools", cexec: "setthe_path('http://......&geturl=true');", npos: 0 } ); app.addmenuitem( { cname: "mygetthe_path", cuser: "get the_path", cparent: "tools", cexec: "console.println( the_path );", npos: 0 } );
here javascript console output when running these 2 commands:
setthe_path begin url: http://......&geturl=true ohandler: [object object] path: trustednethttprequest begin trustednethttprequest end setthe_path end response method: setting path <<https://......desiredfilename.pdf>>
here function in c++ plugin, additional steps prove afexecutethisscript works here
sprintf(jsscript, "testval='%s';event.value = testval;", strurl.c_str() ); afexecutethisscript( apddoc, jsscript, &preturnvalue ); // after this, preturnvalue passed-in url, expected. sprintf(jsscript, "setthe_path('%s');event.value = 'step 1 worked!!';", strurl.c_str() ); afexecutethisscript( apddoc, jsscript, &preturnvalue ); // after this, preturnvalue 'step 1 worked!!', expected. sprintf(jsscript, "event.value = the_path;", strurl.c_str() ); afexecutethisscript( apddoc, jsscript, &preturnvalue ); // after this, preturnvalue null
this javascript console output when running commands using plugin (debugger mode, waiting after step 1)
setthe_path begin url: http://......&geturl=true ohandler: [object object] path: trustednethttprequest begin trustednethttprequest end setthe_path end
note never gets 'response method' portion.
thanks!
tim james
my instincts (and know of plug-ins, nothing of net.http) should avoid javascript. yes, there few unavoidable places, seems unreliable somehow (what happens if user turns off javascript, example).
in case, see no reason not use available interfaces c/c++. there few limitations on if fancy asynchronous stuff. wait may long plug-in shouldn't directly wait, blocks acrobat. (though file > open maybe appropriate). can use threads enormous care since "master" thread can use acrobat api. cannot directly wait-on-event in acrobat api, best can have timed callback.
More discussions in Acrobat SDK
adobe
Comments
Post a Comment