Plug-in Framework

Outside developers are able to maintain their own dll's.  They can publish them, sell them, or keep them private.  Plug-ins are an extension of the Program Links framework, so a button can be placed at the top of any module.

Hooks
In addition to the obvious buttons from Program Links, any number of hooks are allowed. We will add hooks wherever any programmer needs them. Once we define a hook and what information it will pass, a plug-in can start to make use of it.    Hooks will be backported to beta versions if needed in order to allow very rapid implementation.  We expect there to eventually be hooks in thousands of locations throughout the program.  Almost anything can be done with hooks and plug-ins that can be done by directly altering the main program. 

Database
A plug-in can connect to the database through the framework and does not need to manage database connection info.  If the plug-in makes use of extra database tables, the plug-in dll needs to create and manage those tables.  If a developer is releasing a plug-in for others to use, they will probably want to maintain multiple versions, one for each minor release.

Security
Only an administrator can enable a plug-in. This avoids the potential problem of malicious plug-ins being created to hack the database.

Limitations
- Plug-ins should still not make changes to existing database tables.   Plug-ins will have to use their own tables instead.
- Plug-ins should not extend existing enumerations.  We don't yet have a good idea how to accomplish extending enumerations.  Because they are database related, it might not ever be possible.
- Security permissions should be extensible so that plug-ins can add their own permissions if needed.
- Plug-ins will probably not be written to work with our Web Service framework.  They could be, but the learning curve for outside developers would be too steep.  So, for now, we assume that they will only work with direct connection, and plugins will not load if connected through the web service.

Example - Simple Installation
This is a very quick way to download the example without needing to have any programming skills.  It only works with version 6.8 which has not been released.

1. Download this file:
https://70.90.133.65:23793/svn/opendental/PluginExample/bin/Debug/PluginExample.dll
and save it in the C:\Program Files\OpenDental\ folder.

2. In the Main Menu, Setup, Program Links, add a new program link and fill it out as shown below

3. Restart Open Dental.

Example - Complex Installation
These instructions are for programmers who are ready to start building their own functionality.

1: Download the PluginExample solution (https://70.90.133.65:23793/svn/opendental/PluginExample/) using Tortoise.  Put the PluginExample folder in a folder next to the head folder, just like it is in our Subversion folder organization.

2: Open the solution (.sln file).  You may get errors about some projects not being found.

3: To fix the errors, remove both the OpenDental project and the OpenDentBusiness project by right clicking on them in the VS Solution explorer.  Then, right click on the solution and add existing projects.  Browse to ...head\OpenDental\OpenDental.csproj, and add it.  Also, browse to ...head\OpenDentBusiness\OpenDentBusiness.csproj, and add it.

4: In Solution explorer, expand the PluginExample project, References folder.  Verify that the references to OpenDental and OpenDentBusiness do not have red exclamations beside them indicating that they would be broken.  If the references are broken, remove them and add back references to those two projects.

5: In Solution explorer, right click on the project, Edit Properties.  Go to the Build Events tab, and edit the post-build event command line.  Carefully fix the absolute path to the batch file that is included with the example.

6: Find the batch file using Windows explorer, and carefully fix the absolute paths contained within it.

7: Try to build.  If no errors, PluginExample.dll will now be found in the debug folder of OpenDental.

8. Set the Open Dental project to be the startup project (right click).  Test the new features.

Features in the Example
If the example is installed as described above, the following features should be functional:

1. Patient edit window replaced with an alternate.  It's an obvious switch.  The new one has only one field in it, but that field is fully editable.

2. In Account module, hover over the "Ins Left" label at the upper right to see a floating pane with an insurance breakdown in it.

3. A database table will be created and plug-in version managed.

4. Pushing the toolbar button for the plug-in launchs a form.

Hints for Programmers
When using a plug-in, some things are done a little differently

1. To access the private controls on an existing form from outside the form, look through the public Controls property as shown in the posted example.

2. Your new classes will have static methods that get called from the plug in.  One option for implementing the other necessary members of the class that don't get called directly from the plugin is to use the singleton pattern.  As in the example, a static instance of the class is stored within itself.  All the non-static members in the class can then be accessed through that instance. Pay attention to static vs. non-static if you do this.  It's a little trickier than in the main program.

3. More of your methods and variables will probably be public.

4. If managing your own database tables, remember that the plug-in may be turned off and then turned back on a few versions later.  So you can't depend on the same pref that tracks database version.  You will have to store your own database version pref.  If you add rows to the preference table, be sure that they are very very unique.  Make sure to prefix them with a string that would be impossible for us to accidentally duplicate, as we did in the example.