Add-in configuration how ?

[Danny F]

Hi all

I'm writing an Add-In (Proof of concept)
Certain functionality in the add-in must be 'configurable'
for example : the add-in creates sub-package - but the parent-package should be configurable.

What would be the recommended way of realizing this

thanks

[Geert Bellekens]

Danny,

I recently added a configuration file to my add-in EA Navigator.
I'm creating an .config xml file and I'm using the .Net ConfigurationManager to manage the settings.

That works quite well. In my case the .config file is stored in the users profile, so each user can manage his own settings.

See https://github.com/GeertBellekens/Enterprise-Architect-Toolpack/blob/master/EANavigator/NavigatorSettings.cs for the settings class and
https://github.com/GeertBellekens/Enterprise-Architect-Toolpack/blob/master/EANavigator/NavigatorSettingsForm.cs for the settings form.

Geert

[Paulus]

Hi Danny,

Also worthwile to consider: use the EA repository itself to store configurations in a private (user) package.

Let your add-in check for a named model element '<youraddin>Config' of eg type class in some private 'workspace' package of the logged in user. You then could add to that element an attribute for each configuration property your add-in requires, setting the initial value of the attribute to the value of the property for that user.

Each user can configure the settings as they like.

To locate the private package you could use the name of the current user: first try Repository.GetCurrentLoginUser and if that throws an exeception (no EA security installed) use the WindowsIdentity of the current user as an alternative. I use this method to create a private workspace for each user in the repository in a root model 'Workspaces'. One step further: if the current user has no private package (new user), create one and create a default configuration in it.

Note:
- that the configurations are only known once the repository is opened. This can be a drawback or an advantage, depending on your needs.
- a user has to check out the private package to prevent others from changeing settings (but that's common sense when using a private workspace i think). I suppose the add-in could do that as well when creating the package the very first time.
 
best regards,

Paulus