RDL custom reports
RDL custom reports
I've written quite a few custom reports (RDL files) which developed problems with user-entered parameters as Open Dental was updated. At first the parameter screen would only take input the second time it was entered; in version 5.4 and 5.5 it actually launched the parameters screen again after running the report and wiped out the previous results. One way I was able to fix this was by creating a Report parameter for user input and linking it to the value of the Query parameter, then changing the value on line 172 of FormReport.cs in Open Dental to "viewer.ShowParameterPanel=true", as well as deleting the old method of creating a parameter interface thru the query. Now we're able to get some reports functioning again, using the parameter entry interface in RdlDesigner. Wouldn't it be easier for users to do that rather than to build user interfaces for entering parameter values from code and try to integrate them into Open Dental? Or have Custom Reports simply launched in RdlDesigner to get the functionality of printing to a PDF file? Of course, a few MakeReadable functions and some way to convert dates (still looking into this, format doesn't seem to be quite MySQL compatible) would be helpful from ODR.dll, but I'm looking for a way to make reports completely customizable for anyone with knowledge of MySQL query language and the RDL designer, without having to alter Open Dental code.
-
jordansparks
- Site Admin
- Posts: 5742
- Joined: Sun Jun 17, 2007 3:59 pm
- Location: Salem, Oregon
- Contact:
There is a lower level problem to consider: connecting to the database. For example, what if user had opened two copies of OD? The current way would connect to the last database opened regardless of which database the user was in because it uses FreeDentalConfig.xml to get the connection data. It also won't work with the 3-layer framework that we built because there is no direct connection to the database available.
As for parameters, I have found the parameter UI to be very limiting. For these two reasons, my current strategy is actually to build a UI in C# for each report needed. These UI's could be reusable or generic if needed. Then, use OD itself to get the data reliably and securely. The dataset then gets passed to RDL, without needing either connection or parameter info. This also allows us to powerfully shape the dataset before passing it off. You will see that this is the technique we used in FormRpPaySheet. So basically, we have only one report that currently uses this strategy. And that report works quite well.
Where to go from here? Maybe it's time to branch the reporting frameworks slightly. I am no longer interested in the Custom Reports framework as it currently exists. So I am fine with making the changes you suggest to the Custom Reports framework . Whatever it takes to make your reports work is fine as long as it doesn't damage FormRpPaySheet or either of the two Accounting rdl reports that are less refined than FormRpPaySheet. We currently have no use for the Custom Reports menu option, so you can adapt it however you want.
To that end, I created a new form called FormReportCustom in both version 5.5 and 5.6. Custom reports will now use this new form, allowing you to alter it however you need. I have committed the changes. I can also carry future changes back to 5.5 because I consider the current state of affairs to be a bug.
As for parameters, I have found the parameter UI to be very limiting. For these two reasons, my current strategy is actually to build a UI in C# for each report needed. These UI's could be reusable or generic if needed. Then, use OD itself to get the data reliably and securely. The dataset then gets passed to RDL, without needing either connection or parameter info. This also allows us to powerfully shape the dataset before passing it off. You will see that this is the technique we used in FormRpPaySheet. So basically, we have only one report that currently uses this strategy. And that report works quite well.
Where to go from here? Maybe it's time to branch the reporting frameworks slightly. I am no longer interested in the Custom Reports framework as it currently exists. So I am fine with making the changes you suggest to the Custom Reports framework . Whatever it takes to make your reports work is fine as long as it doesn't damage FormRpPaySheet or either of the two Accounting rdl reports that are less refined than FormRpPaySheet. We currently have no use for the Custom Reports menu option, so you can adapt it however you want.
To that end, I created a new form called FormReportCustom in both version 5.5 and 5.6. Custom reports will now use this new form, allowing you to alter it however you need. I have committed the changes. I can also carry future changes back to 5.5 because I consider the current state of affairs to be a bug.
Jordan Sparks, DMD
http://www.opendental.com
http://www.opendental.com