There is no COM object/method to save and restore string filters.

After reading your request, I was wondering why you need such a function. Changing and restoring settings using COM for an automated process is one thing, but in such automated processes you don’t need filters. Filters are used defined data, stored in the user's directory. They can be used in the UI, but not in automated processes, and they will not change in your automation.

You are right, I don't need the filters throughout the automated process.

But the problem is, that all existing user defined filters get lost because I can't store them before I start automation and restore them after automation has finished. There exists only a COM command "objPSL.Import(file name)" for importing an .pslopt file but not a corresponding COM command for exporting/saving such a file.

Therefore I had to use the COM command "objPSL.Option[-number]" to save each single Passolo setting in an array and restore them using the same COM command from the array. But unfortunately the filters are obviously not considered as settings/options (my code consideres all via COM reachable settings). So I need the partly manual workaround described in my first post (that's not a really serious problem, but a bit unconvenient for the localisation team and also error prone).

I wonder why there exists only a batch command ("save") for exporting all Passolo settings (inclusive all filters) in an .pslopt file, but no corresponding COM command.

(By the way, I wonder what are the criterias to get a high sentiment score, 4 stars for my first post, now only 2 ;)

As mentioned, filters are user settings, not accessible via COM. You can the filter filters.dat in C:\Users\<username>\AppData\Roaming\Trados\Passolo 2022 where you can store and save the file.

I have no idea of what the sentiment score is calculated.

Ok, I found a filters.dat file at the location you described. But the file is a few weeks old and does not contain the user defined filters I created for testing a few days ago. If the filters are not always automatically saved in this file by Passolo, that doesn't help us .

Thus, it seems that we have to stick to the current solution with manual export of the filters via the export dialogue each time we created a new filter and automatically restoring these filters via COM at the end of an automated Passolo workflow.

Have you scrolled down within the file? After leaving Passolo the filters.dat will be updated and then it contain all the filters that I have defined.

Ah ok, I had to look at C:\Users\<username>\AppData\Roaming\SDL\Passolo 2018. We still use Passolo 2018. The 2022 folder contains data from the BETA version I tested last year. Apparently data is still saved there, even though I had uninstalled the 2022 version.

The filters.dat actually contains the test filters I created. If it's possible to load the filters via COM command obj.ImportOptions() it would be exactly what we need.

I try to implement the use of filters.dat in my code asap. Many thanks for your help!

After some tests I found a final solution for the filter issue. 

1) When the tool starts I need to make a copy of filters.dat.

2) Exchange suffix .dat by .pslopt.

3) Insert the first 4 lines of a typical options file in front of the filter definitions to create a valid options file.

When importing the Passolo settings required for automation process from a separate options file, existing user defined filter settings get lost.

4) Before the tool ends I import the formerly saved filter definitions via COM command objPSL.ImportOptions(.../filters.pslopt).

So all in all it's relatively easy to implement.

Thanks again for your really valuable tip about the filter.dat file!

First few lines of filter.pslopt (inserted lines from another .pslopt file highlighted):

For a final solution I had to add two additional process steps.

1) I noticed that project filter settings get also lost. Project filter settings are automatically stored by Passolo in file prjfilters.dat in the same folder as filters.dat. Therefore it's required to make also a copy of prjfilters.dat when the tool starts and then create a filters.opt file that contains both string and project filter settings.

2) I also noticed that I need to explicitely encode the filter setting texts to USC-2 LE-BOM (UTF-16) when storing them in filters.opt file. Otherwise German umlauts get lost when importing filters.opt file again and lead to ugly texts in the filter dialogues.

These two steps were also fairly simple to implement. Now everything work as desired.