WAI
Status Update
Comments
kr...@gmail.com <kr...@gmail.com> #3
Hello there,
Thank you for reporting this! However, it seems that this is the expected behavior as the method will return the valid named ranges. Would you be interested in turning this into a feature request instead? If yes, how would it impact your organization in terms of costs and productivity?
kr...@gmail.com <kr...@gmail.com> #4
Sure, please make it a feature request. It would be useful for automating the maintenance of named ranges across a large number of sheets, which is what I was trying to implement 3 years ago when I logged this issue. I don't know how much time is spent manually checking and fixing corrupted named ranges, but certainly some amount each week.
ja...@google.com <ja...@google.com> #5
Hi,
Named ranges help a lot to write dynamic scripts that do not require static range references. And it is crucial to have a good way to define, delete and manage named ranges within app scripts. Especially manage invalid named ranges.
Named ranges help a lot to write dynamic scripts that do not require static range references. And it is crucial to have a good way to define, delete and manage named ranges within app scripts. Especially manage invalid named ranges.
ch...@gmail.com <ch...@gmail.com> #6
Thank you for the details provided! I have forwarded them internally.
Best regards
jp...@gmail.com <jp...@gmail.com> #7
+1 please fix this
jp...@gmail.com <jp...@gmail.com> #8
I really need this feature, as my workflow often involves maintaining a collection of tabs, each having many named ranges in common. That is, I'll create a new worksheet by duplicating a "template" sheet, and then populate it with data. Older sheets eventually get deleted, which produces a growing collection of defunct named ranges.
I haven't found a way to delete them in bulk via the Sheets UI either. In fact, it's a surprisingly tedious process because the UI resets the viewport to the very top list item after each deletion, forcing the user to manually perform O(n-squared) scroll wheel rotations.
I would be really grateful if this were fixed / added.
Thank you
I haven't found a way to delete them in bulk via the Sheets UI either. In fact, it's a surprisingly tedious process because the UI resets the viewport to the very top list item after each deletion, forcing the user to manually perform O(n-squared) scroll wheel rotations.
I would be really grateful if this were fixed / added.
Thank you
ba...@gmail.com <ba...@gmail.com> #9
+1
ro...@gmail.com <ro...@gmail.com> #10
I have run into this bug earlier this week.
Any chance of progress?
In particular, named ranges that are on a deleted sheet (tab) can hang around and do not show up through the Spreadsheet.getNamedRanges(...) call.
The Spreadsheet Editor is doing something out of band wrt the API to see these objects but from App Script I can not see them.
Any chance of progress?
In particular, named ranges that are on a deleted sheet (tab) can hang around and do not show up through the Spreadsheet.getNamedRanges(...) call.
The Spreadsheet Editor is doing something out of band wrt the API to see these objects but from App Script I can not see them.
co...@gmail.com <co...@gmail.com> #11
I need this ... it's a nightmare having to do it manually
co...@gmail.com <co...@gmail.com> #12
This request would break many of my scripts as we are relying on the broken named ranges not being found and we would otherwise often have duplicate named ranges with the same name. Please make it an option to also select the broken named ranges which is off by default
Description
Version used: 1.0.0
Devices/Android versions reproduced on: All
I'm having problem with proper handling of system locale change. Currently I'm resolving some of the strings in ViewModel like:
public class SampleViewModel extends AndroidViewModel {
public final ObservableField<String> statusLabel = new ObservableField<>();
public SampleViewModel(Application context) {
super(context);
statusLabel.set(context.getString(R.string.labelString));
}
}
When user changes locale in system, Activity gets recreated and obviously ViewModel survives configuration change keeping string, that is now invalid due to different locale. I wonder what is the official way to handle such cases using ViewModel ?