Terry,
>1) There are properties and code to track the EntryPointNameList and
EntryPointNameToCookieMap. I'm assuming this is because of the concept
of a DPM AddIn having multiple entry points, which requires a way to
keep track of them and link them to their Cookies.
Correct
>2) There is an AddInPath in the DPM version, but I suspect that (like
make other subtlties) is simply an implementation choice made by the
developer who happend to write this class. Like I said there are lots
of these types of things that seem to be irrelevent, but this was the
most significant of the incidental differences, like error trapping,
asserts, etc.
The AddInpath in the DPM version could be compaired to the MacroAddInpath of the ShapeAppMacroRecordingCSharp sample. This is an incidental difference and is present because only one specific add-in is being loaded. This is an implementation decision and could have been done differently.
>3) As we discussed in earlier posts, the DPM code uses the
EntryPointNameList as a second parameter of the LoadAddIn, rather than
a single StartUp Class. Again, I attribute this to the fact that DPM
AddIns can have multilpe entry points
Correct- this allows it to load with multiple entry points. The list is also used for other DPM "duties"
>4) Here's an odd one to me. In the Disconnect method the DMP chooses
to perform a controller.Shutdown(). Is this a DPM only thing, or
something that should have been done in both implementations?
There's a little more to this- check out the UnloadCurrentMacroAddIn method of the ShapeAppMacroRecording class for another example of this. Don't worry about this too much right now.
5, 6, and 7 I'll have to look into, but for now I gotta run.
Thanks,
-Melody