I would definitely not use ProcessBook.INI file as you cannot predict what will happen with your settings when processbook is upgraded.
What makes more sense to me is to use the .Net settings files, this creates an xml file: app.exe.config that is created when you building your application.
If a setting is modified that is in user scope, .net automatically creates the file in %appdata% for you, and you have nothing to worry about.
There is a lot to learn with setting files, you can have several, even in libraries, but at the end the data gets in the main.exe.config file, it really worth it to have a look.
As mentioned, I'm developing a docking window addin for ProcessBook, so it's basically just a dll.
The customer already have 3 other dataset and docking window addins installed in all their end user computers, so ProcessBook wouldn't be upgraded before I say so
My addin is duplicating the functionality of the ERD addin, and is then extending that functionality by allowing cross display navigation. It also contains some nifty features for adding elements of interest based purely upon Element Categories set in AF. So there is no config or anything, except for what you configure directly on the elements in AF, it's fully integrated with ProcessBook and AF, and thus I'd like to store user settings the same way as ProcessBook does. And it should be locally at each client computer.
The good thing about procbook.ini is that a copy is made and put into the AppData folder for each user of a computer. So it wouldn't matter if it was a single-user laptop or a multi-user terminal server - the setting would be stored in the user's AppData procbook.ini
And basically, the only user settings I'd like to store would be the id of the menu section the user last looked at. (I have different menu sections for each department in the customer organisation, and the idea is to open ProcessBook with the same section pre-selected every time. People from one dept. rarely navigate to other dept. sections, so I'll just be storing the last used section and re-apply that the next time PB is opened)
But if you say it isn't possible, even after considering your warnings, I'd probably be better off writing the setting to the user's registry.
Setting up a User type application setting was considerable less work than arranging for a registry key to store my parameter, so I went with that!
I was about to answer back but I can see that you have found your way with the use of Setting files, great!
I am very happy that this helped you.
Talk to you next time.
Just to add further information, the newer PI ProcessBook add-ins that we deliver out of the box tend to use this config file approach as well. Thanks, Patrice!