IssueTracker

Thank you for your feedback Scott.

We are looking into this.

Best,
Anton

any ETA on this? I'd love to see it work properly

I have the same problem - is there a way to fix it?

As a workaround, find a way to store your remote data on a local sheet. In my case, I had to write some code to periodically update my local sheet to keep it current.  It updates every time I open the spreadsheet, which is deemed sufficient for my purposes.

Define a named range that encompasses all of your imported data.  Next,  hide the worksheet,  since you don't need to see it.

Finally, adjust your custom functions to take the named range you defined as an argument.  You don't have to do anything with that rsnge; just referencing it is sufficient. Now,  when you import fresh data, the data in the named range will change and any formulas referencing that range will be recalculated.

Example: instead of =totalhours(D2:D7) do =totalhours(D2:D7,somerange)

A main problem is forcing the users to manually turn their GPS on, without them wanting to. It's off for a reason!

Stop and ask how the users of Android feel, when they have to manually go into the settings and then enable GPS so that an app can scan for Wi-Fi - What they would consider to be two separate and unrelated elements of their device.

And then the users will ask the question: "why can Google scan for wi-fi access points, but this app cannot? Why does it need GPS turned on? I do not trust this app."

Google are punishing their developers and users. Those who have built safe apps will have them removed by users and rated 1 star because they do not work as intended. Those who have built unsafe apps might as well use just GPS when available, since it's more accurate and the permissions have already been accepted, at the cost of battery consumption for the user.

AND UPDATE THE DOCUMENTATION! http://developer.android.com/reference/android/net/wifi/WifiManager.html#getScanResults() 

I have the same issue in Chrome on Ubuntu linux.

I'm simply trying to reseed a random number, so I can't use the workaround referencing changing data. I tried it with the hidden range including a RAND() function of its own, but it created a circular function-updating effect that normally took several seconds to resolve or would timeout.

None of these appear to be real issues.  Custom ss functions are deterministic. They will only recalc if one lf their parameters change, thus the old value gets cached.. You are not supposed to rererence anything outside the In Params  if you want to use it on a cell formula.

I still think this is nog functioning properly: I created a simple custom function to count characters in a textstring.
I also added a parameter to determine whether this has to be case sensitive of not: I added this paramater in calling sheet and pass it to the function via a parameter.
The first time i change the parameter everything works out fine, but when the same value (0 or 1) is used again the function isn't re-evaluated anymore. Even with different a different parameter value.

to the coment above: its still by design. Its not that the function gets re-evaluated when you change parameters. See what a deterministic function means. Given the same input, it will give you the same output. You cant have outside dependencies, it must only depend on its parameters. In your case, it depends on an outside string thats not in the parameters.

This issue should be closed. Its also a dup of issue 36758344.

please fix this

This really limits the usability of custom functions to get at data, like the sheet name or a remote value, automatically. For example, naming the sheet after a person (or other query parameter), then using =QUERY(..., CONCAT(...), ...) is a very nice way to allow users to create custom query pages by copying a sheet and changing its name. Please allow us to mark a function declaration or call in such a way that reloading the sheet forces a recalculation. Thanks.

I had a custom function that depended on values in a configuration sheet. Scott's workaround of passing in the named range of the configuration sheet work well for me.

The inability to get a sheet name is kind of crazy. When you can't code what your eyes see right in front of you, that's rough. Users need intuitive solutions, and it'd be nice to be able to code so that sheet names -- renamed at users' discretion -- could be active variables in code. The names need to matter as DATA -- not just eye candy.