Clarify bound script limitations

[dandv]

Currently, it reads:

Your add-on must be developed as a standalone script and tested within Doc or Sheet. This means that it cannot use certain functions of bound scripts, namely installable triggers. While testing within a Doc, you have access to the "Special methods" mentioned in the docs, though. If you followed the quickstart above, you should be set up correctly.

The "While testing within a Doc, you have access to the Special methods" part confuses me: for my script I absolutely need the getActiveRange() special method. I can use it during testing indeed, but is that relevant if the script must be ultimately deployed as a standalone script?

FYI @pietergreyling

[0cjs]

An Add-on is always a "standalone" script, i.e., the code is in its own Script document rather than part of a Spreadsheet document or whatever. An Add-on is attached to a document in one of two ways: a) via the testing interface, or b) via publishing it, a user adding the Add-on to his personal list, and then using it in a document.

In each case, the script has access to the "special methods" mentioned above.

(Triggers are a whole different issue, BTW, since as far as i can tell they are not actually part of a document, but really more part of a user account.)

[hess-g]

A clarification - It is possible to publish an Apps Script project as an add-on even if that Apps Script project is container bound (created from and associated with a document or spreadsheet). It is recommended, however, that you use a standalone script. In that case, during development you can use the "Publish --> Test as add-on" feature in the script editor to mimic the installed behavior. Once published as an add-on, and associated with a document or spreadsheet by a user, it behaves in large part like a container-bound script: You get access to things like SpreadsheetApp.getActiveSpreadsheet(), you can install triggers for the user, etc.

As relates to gapps, the limitation is that if you have developed your add-on as a container bound, as opposed to standalone, Apps Script project, you can't currently use the Drive API to upload code, which in turn means you can't use this tool.

[hess-g]

If you want to test or debug your host-interaction functions, ones that would depend on active host methods like "SpreadsheetApp.getActiveSpreadsheet", you can look at some very simple code I included with my post on development techniques. For example, I included a helper method that provides the right instance of the active spreadsheet - If you have configured an ID in your code, it opens that file, otherwise it tries to use the getActiveSpreadsheet method. You can see that code here. This would allow you to have some degree of debugging and testing from right within the editor.

[omarkj]

Related to the general clarification of bounded v. standalone scripts.

Is it possible to provide access to custom functions in Sheets from a standalone script (that has been bound to a Sheet, for instance using Test as?). I am having no luck doing so.