Developers

Certain developers are allowed to make changes to the source code on their own. Warning!! Code downloaded using methods listed on this page is NOT suitable for use in a live setting. A database using such code will be unable to upgrade later to a newer version.

IDE - Most developers work in Visual Studio on MS Windows computers.  Many developers also use C# Express version with no problems. Some developers work in Mono and compile using NAnt. Any of the above methods will work.

Subversion - You'll need to install the TortoiseSVN http://tortoisesvn.net  Subversion (SVN) client (or any other SVN client of your choosing). We are keeping things very simple by not using any branching or merging.  Everyone works on the head. For example, let's say the head is version 4.7.0.  No offices would ever be using this version.  After about 60 days of development on version 4.7.0, it would be moved to beta status, and the build numbers would start incrementing.  It is very critical that no new features be added at this point, as the only goal is stability. After a few days to a week, access to version 4.7.x by external developers would be closed (technically, this is a branch).  The head would then become version 4.8.0, and all work would move to that version. The beta version, 4.7.x in this example would remain in beta for 30 to 60 days or until it was clearly shown to be bug free.  During this time, the only changes that would be made would be bugfixes.  This is different then it has been in the past, when a number of small features were typically added during beta testing. So the bug fixes would first be applied to the head, 4.8.0, and then we would handle merging select bug fixes into the beta version, 4.7.x. If everyone was careful, there should hopefully be few changes that need to be made to 4.7.x.

Simple Subversion Instructions
If you've never used Subversion before, please read some documentation (see the basic concepts chapter).   And if you're not sure what you're doing, ask for help.  At first, please only make very small changes so that if you do make a mistake, it will be easier to fix.  Some very basic guidlines to get you started:  Tortoise commands are accessed by right clicking on folders and files from within Windows Explorer.  So first, create an empty folder on your computer named OpenDental4_7 (for example).   Then right click on the new folder

and select SVN Checkout.  The following window will come up, and you'll need to copy and paste this URL into the first box:
https://70.90.133.65:23793/svn/opendental/head. Change "head" to "opendental4.7", "opendental4.6", or "opendental4.5" to download those versions.  But changes can only be made on the head, which is always one version ahead of the production version. You can also browse older versions at https://70.90.133.65:23793/svn/opendental/

Click OK and then accept the security warning.  This will fill your folder with the current source code ( 8 MB ). From then on, you'll perform an "update" whenever you want to update your folder to the most current version that everyone else is using. You can do this frequently. 

Commit privileges - Only certain programmers are allowed to make changes. Once you are very familiar with the code and have been using Open Dental for a long time, you might make a change that you want to share with everyone. If you do need commit privileges, then you will need to call us. We will need to talk with you to make sure you are very familiar with Open Dental and with the source code. If we do decide to let you have commit privileges, then we will need the following information for setting up Subversion:
username
password
email
name
phone number
Please tell us if you would like to receive e-mails when any commits are made.

If you have made a change to the source code that you want to become part of the repository, then you'll use the "commit" command.  But before committing, always perform a clean update first.  If the update makes changes to your local working copy, compile again just to make sure it still compiles. Then, commit.  If you ever add a file to the source code, you'll need to perform an "add" on the file before committing.  You might also have to make a comment in the code explaining why you made a certain change if it's not obvious. So the collaboration is not integrated into VS. Instead it's a file-based system.

Rules
Rule #1: Every commit must compile.
Rule #2: Every feature added by an outside developer must be discussed first on the forum under its own thread. If a feature is added without discussion, there's a chance that it will be unceremoniously deleted.
Rule #3: The commit should be as small as possible. This usually means one bug fix per commit, or one specific feature addition.  If the bug fixes are very small, you could include a few in one commit.  If you are adding a large feature, still try to commit it in small pieces so that it can be more easily reviewed.
Rule #4: Conform to the Coding Style currently in place, especially indentation (you must change this setting), language enabling, and Oracle.
Rule #5: Use our Boilerplate Code whenever possible.
Rule #6: Start slow and start small.
Rule #7: Be very aware and careful not to break any existing functionality.  There can be subtle and complex relationships in place.  If you don't thoroughly understand a section of code, then don't even think about changing it.

Our internal paid programmers might not completely follow the above rules, especially #2. Also, the Future Versions page that we use to prioritize does not apply to everyone else.  It's perfectly acceptable to have your own priorities and to add a feature that we consider to be a very low priority.

Bug Tracker - We now have our own bug tracking software that we built. http://70.90.133.65:1942/ODBugTracker/BugList.aspx  It's actually just a different interface for our Previous Versions page. It might be possible for anon users to post a new bug, but other than that, we are keeping the bug tracker internal for now. We heavily manage the bug database to keep it very current.  If it's a very obvious bug, it might be ok for you to fix it immediately.  But generally, you would first discuss the bug on the forum.  The reason for this is that it might not actually be a bug, or we might have comments about dependencies to watch out for.  In general, we are very on top of bugs, and there should not be much need for anyone else to fix bugs.

New Features, Hot Topics

Screen Space
There is limited screen space to work with.  One issue that is a common source of disagreement is which fields are the most important to display given the limited screen real estate.  In particular, the Patient Edit, Family module, Chart module lower left, Appointment Edit, and Appointment module.  The general strategies for all of these areas are.
1. Use vertical scroll bars to continue to pack information into the same physical area.  See the example in the InsPlan Edit window, left side (the screenshot is out of date and does not show this). This also works great for any existing grid.
2. Use combo boxes in simple list mode instead of list boxes. List boxes can continue to be used on other screens where space is not at such a premium.
3. Pack the controls closer together.
4. Use the Easy Options to hide fields that most users would consider clutter.
5. When a window gets too full, such as the Appointment Edit window, then we need to be involved in trying to make more space for the data.
6. Give the user control over which fields show. This can be seen currently in the Display Fields feature for the Chart module.  It is planned to expand it for the Patient Select window.
7. Move some fields out. An example is the referral grid, which was recently moved out of the Patient Edit window.

The eventual solution for the Patient Edit window is going to be to just make the entire thing dynamic and generated on the fly. The whole thing will scroll vertically. Users will have a place to specify exactly which fields they want to see. This would remove any limit to the number of fields that could go in that window. And Custom Patient Fields would appear to be just as available and important as hard-coded fields.

Database Fields
Everyone wants more fields. Everyone has different priorities on which fields are most important.  In the past, we've only added fields that we had time to implement and manage in the user interface.  But we will have to start allowing the addition of many more fields to accomodate the needs of the many different developers.  Here are some considerations regarding new fields:
1. The patient table is very full, so can it be put in some other table?
2. If it's a long "text" field, and you're considering putting it in the patient table, then it really belongs in the patientnote table.
3. If it's a patient field which is very specific to one office, could a Custom Patient Field be used instead? This would be much simpler because it would require no programming.
4. You must be prepared to fully implement your new field and tie up all loose ends.  If it's buggy, you'll need to work on that before moving on to something else.

If you've considered the above details, and you're ready to add a new field, then here are the typical steps you'll take:
1. Discuss it on the forum.
2. Go to OpenDentBusiness\TableTypes and add the field.
3. Go to OpenDental\DataInterface and add the functionality to all methods for the appropriate class, including Refresh, Insert, Update, Delete, etc.
4. Add the "ALTER TABLE" command to Misc\ClassConvertDatabase.  Remember to include a second alternate command for Oracle tables.
5. Double check the punctuation in the SQL.
6. Commit.
7. Add space and functionality in the UI, following the guidelines above in the Screen Space section.
8. Test it thoroughly.
9. Commit.

Database Tables
New tables are actually much less of a problem than new columns on existing tables. The reason is that they do not affect existing functionality at all. Feel free to add any new tables that you want.
1. Discuss it on the forum.
2. Create a new class in OpenDentBusiness\TableTypes.
3. Create a new class in OpenDental\DataInterface.
4. Add the "ADD TABLE" command to Misc\ClassConvertDatabase.  Remember to include a second alternate command for Oracle tables.
5. Commit.
6. Create a user interface. Probably an entirely new form.
7. Test
8. Commit