Javascript equivalent to Get() in Formcalc?

As a wise man like Thom Parker says:

"The Acrobat JavaScript Reference, Use it Early and Often"
http://www.adobe.com/devnet/acrobat/javascript.php

That's Right!!

Look at "app.launchURL()"

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thanks for the prompt response. The app.launchURL (that is what I tried first thank to a post I saw from Thom) method seems to perform a slightly different action. For instance, If I insert Get(http:\\www.yahoo.com) as a calculate event in text field using Formcalc, I see the HTML for yahoo as text. I would like see the text using Javascript instead of lauching a URL. I would like to manipulate the string data. I truly appreciate the help.
Jimmy

I've never used the FormCalc "Get" function before. Very interesting! In Acrobat JavaScript, the only way to get the results of an HTTP GET is with the "Net.HTTP" object, which can't be called from a document context. So there really isn't anything like this in Acrobat or LiveCycle JavaScript.

But I have a suggestion. If you need to perform some script before or after calling the Get, then place the JS and the FormCalc GET in different but related, events, so they are called one after the other. For example, On a button, put the JavaScript setup code in the MouseDown, then put the Get in the mouse up or click event. Transfer the URL used by the Get in a variable on the button, or in a hidden form field. There are lots of variations how you can call a FormCalc script from a JavaScript. As another example, you could put the FormCalc on a rarely used event on a hidden field, then from JavaScript you can call the event directly.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thanks Thom for the help. I will try your suggestions. As an aside, I found one of your AcroForms XMLData_Example.pdf that does what I am trying to accomplish with an exception. The XML data example uses XML attached to the form inside Javascript, I want to

1. "Get" an external XML using a custom REST request from Yahoo Maps using the following:"http://local.yahooapis.com/MapsService/V1/geocode?appid=YD-9G7bey8_JXxQP6rxl.fBFGgCdNjoDMACQA--&street=701+First+Ave&city=Sunnyvale&state=CA"2. Parse the response to extract Latitude, Longitude, City, State, Zip and Country.

Can this be done?

I can use the Formcalc to Get the text an use the Substr command, but it would be much easier to use Xpath to extract the information. I can't get Adobe to recognize the data as an actual XML document unless it is attached to the form as a Text String.

Any help with the problem would be greatly appreciated.

This is above my head, but it seems like it should be so simple

I think that you are better off using the FormCalc Get fucntion. There is Webservice access from several parts of the Acrobat JS environment, but they are all restricted in some abnoxious way. If the Get() works for you then stick with it.

As for parsing the return data, Acrobat 8 and later has two XML parsers built into it. There's the XMLData object and the E4X Data Type. XMLData is Acrobats own XML spec. It's the same one used by XFA and what's demonstrated in XMLData_Example.pdf . E4X is built-in to Core JavaScript 1.6. If the data you've got contains namespaces or other fancy XML features, then the XMLData object might choke on it. Try the E4X, there's an example of using it, with namespaces in the Acrobat JavaScript Reference on the "Doc.metadata" entry, Example 3.

You can get more, better information on E4X from the Mozilla web site. Since, after all, they are the ones who created it.

https://developer.mozilla.org/en/JavaScript

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

I got the XML returned from the URL you specified and didn't have any problems parsing it with the XMLData object. For E4X I had to remove the first line, i.e. (<?xml version="1.0" ?>)Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

That is awesome, but that just tells me that I have no idea what I am doing :-)
Could you share the code on parsing one of the data?
I have tried in vain for weeks, but I must have been writing the script incorrectly.
Thanks

This what I have, but it is not even close
http://fi9dla.bay.livefilestore.com/y1p2qoX_1vEiY2qKfBECsXW0dSOmL8_SmDXLHZSmCiy4_R9xJZ37sUNXRd0vD33tdzL1QpEwwsp_sVFZPmbMRpP2w/URL_Geocode.pdf?download

First, the calculate event is the very wrong place to put this code. For testing purposes use button click events. One for getting the data and one for parsing it.

For the parsing script. The XMLData object is being created correctly, but I think the name spaces might be screwing up the XPath. I'm not an XPath expert but I think you need to use the namespace prefix.

But this syntax works perfectly with your parsing code.

myXML.ResultSet.Result.Latitude.value

So no XPath necessary.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thank you for the help. I will be sure to give credit where credit is due. I was certain that I needed Xpath to parse the data. This explanation makes much more sense. I tend over analyze and make things more difficult.
Jimmy