I have a feeling that this entire thread might have stemmed from a server-generated error rather than anything else...
There is no real difference (that I can think of) between:
Code: Select all
put URL "..." into tURL
answer tURL
and
Code: Select all
put "..." into tURL
put URL tURL into tContent
answer tContent
If a webserver generates an error you invariably get an error page back which (in its simplest form) will just contain "<error-code> <error description>". Bearing in mind the answer dialog will set htmlText on its message field if it thinks it has been given HTML - that is probably why it *appeared* that an an error resulted in the var, rather than the content of the page (Webservers usually return the error code in some HTML!).
So - I suspect either the URL was typed wrongly in the first example when it was run - or some server-side setup meant the intended page was, in fact, inaccessible at that point.
In terms of parentheses and the URL keyword, then the URL keyword is an 'object chunk' keyword (like field, button etc.) and it behaves the same as all others of those.
Chunk keywords bind tightly to the factor to their right - where a factor is basically any expression which is not a binary operator (and so can't cause an ambiguous 'chain' of things). (Technically, chunk keywords are prefix unary operators with precedence just below all binary operators).
Examples:
Code: Select all
put URL "Foo" into tURL
=> fetches URL "Foo" and places the contents into tURL
put URL "Foo" & "Bar" into tURL
(bracketing to reflect precedence) => put ( URL ("Foo") ) & "Bar" into tURL
=> fetches URL "Foo", concatenates "Bar" to what that returned and places the contents into tURL
put URL ("Foo" & "Bar") into tURL
(bracketing to reflect precedence) => put URL ( "Foo" & "Bar") into tURL
=> fetches URL "FooBar" and places the contents into tURL
Basically, the rules of when to parenthesise what you are URLing should be the same as those which apply to all object/control chunks.
Note: Chunks which *must* have a target (e.g. word, line, char etc.) do *not* need what they are operating on to be parenthesised:
Code: Select all
put word 1 + 2 + 3 of tFoo into tBar -- this is fine
This is simply because the parser that there has to be an "of" (or "to" - for ranges) after the (first) index expression so there is a natural terminator for it, so it doesn't need to restrict to just allowing factors.