Calling OnReadSettingsAsync Explicitly

[DavidLaMartina]

Is it possible to call OnReadSettingsAsync() explicitly, in addition to overriding the method? There are potentially times at which I'll need to access Project-level settings other than when a Project is opened.

Most notably, I might need to access Project-level settings for an Add-In that a user enables after they have already opened a Project. For instance:

1. User A, who has already licensed our custom Add-In, passes a Project file with Add-In custom settings to User B, who has not yet licensed the Add-In.

2. User B licenses the Add-In, which they had previously installed but not licensed.

3. Now that the Add-In is licensed, its settings need to be read from the Project into the Add-In's in-memory settings object.

-David

[GKmieliauskas]

Hi David,

I have similar task and I need settings all time of work with ArcGIS Pro. So I create singleton class with Dictionary type property.

On  OnReadSettingsAsync() I copy all my project settings to singleton. When I need project settings, I call singleton class for getting value I need.

You can use your module class for this if your all Add-ins are in the same module. In other case you can get many cross-references.

[DavidLaMartina]

Thanks Gintautas Kmieliauskas‌ - I'm already doing just that, though. I read in settings when the Project loads and store those in an in-memory object. But that's not what I need in a few specific situations.

What I want to be able to do is access the settings stored in the Project file - not in the Add-In's in-memory object - at times other than Project load. Because of the potential timing issues with loading Projects and licensing, it might be important to access the Project file's settings at other times.

[GKmieliauskas]

David you can manage order of loading Add-ins. So you can make that module which responsible for project settings and licensing will be loaded first. I have the same situation in my development project: project settings and licensing. I call it core module. In the config.daml file of core module add to module attribute

autoLoad="true". For other Add-ins modules add dependencies from core module like this:

<dependencies>

<!-- id of "core module" -->

<dependency name="{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx}" />

</dependencies>

There is no timing issues or other problems reading project settings

[DavidLaMartina]

Huh, I didn't know about adding dependencies. I'm still a little unclear, though.

So, in my situation (sounds like yours, as well), I would actually create two Add-Ins. One of them manages the loading of settings from Project files, and the other does all of the other business logic. The "core" / settings module will be auto-loaded as soon as Arc Pro is fired up. The other Add-In depends on the core module...but what does that achieve? Will OnReadSettingsAsync be fired again when the second module is loaded? I'm just not understanding how this scheme offers access to Project settings at times other than Project load.

[CharlesMacleod]

Hi David, your add-in Module still loads even if you have not enabled your add-in (via, I am assuming, an IExtensionConfig implementation?).

Assuming you are using IExtensionConfig, your module always needs to load to allow you, the add-in developer, to respond to a licensing check from the Pro app (which is usually triggered when the user attempts to "check" or enable your extension via the licensing tab on the Pro backstage).

This means that your add-in will autoload as normal, if that is what you specified in your config.daml, and can listen to the OnReadSettingsAsync callback regardless of its "State" returned from IExtensionConfig. Therefore, the add-in module can retrieve the stored defaults via the callback "as usual" whenever a project opens - even though, to the "outside" world, you may be showing its capabilities (tools, buttons, etc) as disabled.