Posts: 2,085
Threads: 320
Joined: Sep 2014
When I change the MobileSheets library my user defined filters seem to be still there, but they don't work as expected:
The "source types" selection that I stored in the filter selects completely different source type values
The same source types also exist in the other database. When I select them manually filtering works as expected.
I think I understand the reason: in User_Filters.xml source types (and also colllections and other fields) are stored by their database ID, index or the like, but that ID points to a different source type in the other database.
What can be done? Can you fix that easily or could you recommend a feasible workaround?
Posts: 2,085
Threads: 320
Joined: Sep 2014
" The same source types also exist in the other database ..." is not completely correct. Source types with the same names exist, but not all exist in both databases. Probably I have entered them independently. I cannot tell exactly, my MobileSheets history is a long and winding road.
Posts: 14,347
Threads: 302
Joined: Apr 2012
There is no easy solution for this for existing saved filters unfortunately. The filter saving/loading was implemented before the addition of the "Switch library" feature, so I didn't think about the fact that the database ID is being stored which won't work across libraries. I'll have to change this to instead store the name of the group, and then do a slower lookup by name when the filter file is loaded. I'll add this to 3.9.0 list of things to do.
Thanks,
Mike
Posts: 2,085
Threads: 320
Joined: Sep 2014
Thanks for your answer. I'm waiting for even more important features of 3.9.0 anyway ...
Posts: 2,085
Threads: 320
Joined: Sep 2014
(08-12-2024, 03:38 AM)Zubersoft Wrote: There is no easy solution for this for existing saved filters unfortunately. The filter saving/loading was implemented before the addition of the "Switch library" feature, so I didn't think about the fact that the database ID is being stored which won't work across libraries. I'll have to change this to instead store the name of the group, and then do a slower lookup by name when the filter file is loaded. I'll add this to 3.9.0 list of things to do.
Thanks,
Mike
Wouldn't it be easier and more consistent instead of "store the name of the group" to keep the logic as is (using database IDs) and store separate user filters per database? possibly inside the database instead of in user_filters.xml?
That might probably also fix the issue with losing user filters that I reported here:
https://www.zubersoft.com/mobilesheets/f...11270.html
Still not my highest priority, it just came into my mind again.
Posts: 14,347
Threads: 302
Joined: Apr 2012
04-17-2025, 06:59 PM
(This post was last modified: 04-17-2025, 06:59 PM by Zubersoft.)
The filters would then be stored independently for every library. I'm not sure that's what everyone would want... if you define filters you want to use with all your libraries, I would then have to add a lot of UI elements and database code to persist filters across every library that is currently defined, and add options to copy or move filters between libraries. It just starts adding more and more work, but I don't really think it's necessary to save the filters inside the database, because I can just save a name instead of an ID, and that should work fine. I'll think about this some more though.
Mike
Posts: 60
Threads: 18
Joined: Nov 2024
04-18-2025, 02:14 AM
(This post was last modified: 04-18-2025, 02:15 AM by Jazzy Boomers.)
Hello,
Before change this, think about musician category.
Now we have no solution to select pages for type of sheets in relation with musician... (Drum-brass-Rythm-Singer etc)
Posts: 2,085
Threads: 320
Joined: Sep 2014
Most of the filters that I use filter by collection and / or source type. Both criteria are stored in the database. This is why I had to redefine my favourite source types in other databases. That's how different IDs were created what caused the issue. I wouldn't mind having to redefine also the filters, I don't change them often.
That most filter criteria are independently stored in different databases made me think it would make sense and would be easier to implement to store the filters also in the database. But that's your design decision.