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.
Example - Simple Installation
1. Download this file:
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
1: Download the PluginExample solution (https://opendentalsoft.com: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 exclamations beside them indicating that they would be broken.
5. If there are broken references in OpenDental and OpenDentBusiness, they can usually be ignored, but both of those projects must be build from within the head Solution first.
6: 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.
7: Find the batch file using Windows explorer. Right click, edit. Carefully fix the absolute paths contained within it.
8: Try to build. If no errors, PluginExample.dll will now be found in the debug folder of OpenDental head.
9. Set the Open Dental project to be the startup project (right click).
10. Enable the plugin by adding a Program Link as described above.
Features in the Example
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 "Family Aging" label at the upper left to see a floating pane with an insurance breakdown in it. The info in that pane is entirely under the control of the plugin.
3. In the Chart module patient info grid, all referrals show instead of just referred from. Unfortunately, the replaced Patient Edit window makes it hard to test this feature. You may need to turn off the plugin, set up a few referrals for a patient, then turn the plugin back on to see the effect.
4. A database table called jss_dev_myveryuniquetable will be created, and the plug-in version will be managed via an entry in the preference table called Plugin_JSS_DataBaseVersion.
5. Pushing the toolbar button for the plug-in launchs a form.
Hints for Programmers
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.
Usually in combination with the above technique, there is also a trigger available that will load a recently distributed dll. To turn on the trigger, use [VersionMajMin] in the plugin name. For example, the plugin might be entered as MyPlugin[VersionMajMin].dll. The bracketed section will be removed when loading the dll. So it will look for MyPlugin.dll as the dll to load. However, before it loads, it will look for a similar dll with a version number. For example, if using version 7.1.13, it would look for MyPlugin7.1.dll. If that file is found, it would replace MyPlugin.dll with the contents of MyPlugin7.1.dll, and then it would load MyPlugin.dll as normal. In a typical setting, this copy sequence gets triggered every time Open Dental starts up, ensuring a fresh copy of the dll. If Open Dental is on a newer version, and the dll is still on an older version with no matching [VersionMajMin], then Open Dental will attempt to load the old dll.
However, using the above two strategies is not necessary for most developers. There is normally no reason to exclude your dll from the file copy routine during an update. And you can assign a version number to a dll without changing the name of the file.
Open Dental Software 1-503-363-5432