I'm thinking out loud here. I am building a DLL which will provide reporting services to an application. The DLL will be written in XE5 or XE6, but the app it must serve (initially) is in D2007. All well and good, so far.
I'm thinking out loud here. I am building a DLL which will provide reporting services to an application. The DLL will be written in XE5 or XE6, but the app it must serve (initially) is in D2007. All well and good, so far.
Where it gets interesting is that the user will be presented with a wizard for selecting options on each report. The options page(s) will typically contain checkboxes, radio groups, and lists from which things are selected. I was thinking that it would be handy if the DLL could send to the app the specifications for building the pages(s). There would also be some code interlocking control behavior, and each page would have a routine which writes the selected info about options to a dataset which will be passed to the routine which generates the report.
The DLL can't present the form, because we are crossing versions, and moreover, some of the clientside apps are running on unsupported versions of Windows. (I know, I know...)
The benefit I would achieve is that the DLL could provide the specs for wizard pages serving more than one app version, and when options are changed, the DLL would communicate the new specs, rather than our having to update wizard pages in multiple build versions.
Just wondering whether anyone has ventured down this path before.
Where it gets interesting is that the user will be presented with a wizard for selecting options on each report. The options page(s) will typically contain checkboxes, radio groups, and lists from which things are selected. I was thinking that it would be handy if the DLL could send to the app the specifications for building the pages(s). There would also be some code interlocking control behavior, and each page would have a routine which writes the selected info about options to a dataset which will be passed to the routine which generates the report.
The DLL can't present the form, because we are crossing versions, and moreover, some of the clientside apps are running on unsupported versions of Windows. (I know, I know...)
The benefit I would achieve is that the DLL could provide the specs for wizard pages serving more than one app version, and when options are changed, the DLL would communicate the new specs, rather than our having to update wizard pages in multiple build versions.
Just wondering whether anyone has ventured down this path before.
I did something similar for Crystal Reports.
ReplyDeleteCR exposes all the parameters required for the report: their type, range/constraints and all that. I wrapped the CR stuff using interfaces which I pass to my parameter dialog form.
The form in turn dynamically instantiate frames, one frame per parameter. Using frames instead of adding controls directly to the form made it easy to handle more complex parameter types, such as date ranges, as well as neatly encapsulating the load/save logic.
Each frame is initialized with the interface for the corresponding parameter, which has methods for getting the parameter constraints and getting/setting the parameter values.
Thanks to this design we could very easily use the same form for FastReports, which we're gradually switching to, as it doesn't have a native dialog ala CR.
Though, passing interfaces between exe and dll's can lead to issues, so JSON is probably a good idea for your task.
Bill Meyer send me your email address and I'll send you a download link
ReplyDeletemeyer.wil at gmail dot com
ReplyDelete