Convert/Migrate old RB v9 (.BRT) reports to RB v21 (.RTM)

DTWaling

We have been in the process of migrating our old Delphi code to the current version of Delphi. Our app fully integrates the ReportBuilder and includes several pre-made "standard" report templates. I have tried a couple different approaches:

1. I have attempted the steps noted in the readme/release notes - change file extension to RTM and then, from within the designer, open from file. This appears to open the file without error, but also without importing anything from the old template.

2. I have attempted opening from data stream (via the previously imported report templates stored in the DB), and in this case we do get the design elements to show, but none of the configured data sources or procedures are brought in.

In approach #2 I do get an error: "Class TdaIBXQueryDataView not found..."
This is not unexpected since many of the old IBX components in Delphi are migrated to new components, so likewise there are corresponding changes in RB - so my assuption is that TdaIBXQueryDataView is fully replaced by TdaQueryDataView?

Following this conclusion, I could use a text editor of other tool to do a find/replace in these cases in the old RB template files. However, I also assume there must be other classes, and/or properties, that need to be replaced as well. Additionally, in most of our old templates there is an encoded data section, and I am not entirely confident this will carry over cleanly, if at all.
If it was only a handful of Report Templates, I wouldn't mind pushing through, or even re-writing, them manually, but there are a couple hundred.

So, I am hoping somebody has some form of doc or notes for the class and property mappings (like the mappings used for the Delphi code migrations)... or (if I'm really lucky), there is some sort of utility or process to reliably migrate our old v9 RB templates with a few extra steps.

DTWaling

P.S.: I have seen the response in an old post: https://forums.digital-metaphors.com/forums/discussion/comment/33922#Comment_33922

I will be attempting the approach recommended there to see how far I can get. I would still be very grateful for any additional direction or advice, as going from v9 to v21 is a sizeable gap to cover and I don't want to miss anything.

nicocizik

Hi Dustin,

The thread you found gives correct information on how to go about changing report templates to use a different DADE plugin (as it appears I wrote it ) You can also take a look at the following article on how to convert BDE reports to ADO. While the classes will be different, the same concepts apply.

https://rbwiki.digital-metaphors.com/dade/fundamentals-dade/convert-template-bde-to-ado/

Note that the template extension is not important other than the RB dialogs filter for ".rtm". If the templates are saved to DB, the file extension is irrelevant.

DTWaling

Thanks for confirming.
I went back in (with renewed confidence) and finally found all the object types and property values that required an update, and the reports are all pulling in without error, and so far all appear to be correct when reviewing in the designer.
Thank you!


P.S.: I am posting some follow up questions here shortly. But let me know if you would like me to move my follow up questions to a more appropriate forum category.

DTWaling

Thanks again!
As noted, I have a couple areas left to tackle for our legacy code migration.
- I know I may be asking a lot here, so I don't expect direct lessons or walk-throughs, but at least hoping for some references to more in-depth info on these topics.

1. Custom AutoSearch handling:
Previously we had implemented a heavily modified variation of the ppASDlg and ppASCtrl in order to populate the selectable values during user prompt. The modifications did a lot of work to create specific control types to be used when we populated the selectable data from the database, but it seems to me that RB is capable of handling that pretty well on its own already. So, I am working on converting over to more standard usage of existing objects/events. Specifically, I am hoping to make use of the Parameter & AutoSearch events to capture and populate these data. As noted before, I am hoping to avoid modifying each report individually.

So, this is what I am thinking:
I could make a pre-defined parameter set that I can tack onto each report file. And at run-time
- Set the report event handler methods prior to calling print preview;
- The method(s) will inspect existing DataViews to get existing data set & auto-search info;
- Next, dynamically create new "lookup" DataView(s) and link to the predefined parameters;
- Then assign the parameter(s) to the AutoSearch field(s);
Not sure if there is an example of this approach already, but it seems like a feasible route.

I've gone through existing docs, but the detail there is relatively sparse with regard to the parameter & auto-search classes/types I need to leverage. I have also tinkered with a couple of the demos/tutorials, including a couple I found in the forum, and have made some progress. But there seems to be a little more going on under the hood than what I've been able to extrapolate so far, so it isn't entirely clear to me yet what inclusions are implicitly connected to which report behaviors.

I supposed it could be as simple as maintaining common field naming between the "lookup" query and the parameters, but that felt almost too simple, and I have a lot of reports to make this work for, so I really just want to avoid getting lost in the weeds here. (And, admittedly, I have been a bit overloaded recently, so it is quite possible I have overlooked a demo/tutorial or two that could help fill in the gaps.)


2. Designer UI is [being a dum-dum and I think it is on purpose to trigger me when it knows I'm trying to focus on other things... Please somebody tell it to stop.]:
Well, okay, maybe only 1 1/2 things, as this doesn't feel like a "full-sized" issue on its own
I am seeing a very strange effect on the designer's menu & toolbar icons that makes them all have dark backgrounds, but *only* when we execute show form at run-time. We aren't making any changes to designer properties beforehand, so I can only guess that it is inheriting from the parent forms somehow. But none of the main forms are using any sort of dark theme, or otherwise modified icon set.

edited:
I just found a post which seems to answer this question:
https://digital-metaphors.com/forums/discussion/21723/rb-21-03-menu-icons-with-black-backgound#latest


Thanks in advance, I appreciate your time!
-D

nicocizik

Hi Dustin,

Yes, for future reference, it would be best to post this as two new threads to keep the topics separated and searchable.

1. Report Parameters, DADE, and Autosearch are all closely tied together. There should be no need to dynamically create new dataviews, you could simply re-use the existing dataviews and assign the parameter as the search condition using the TdaSQLBuilder class. Also, once a Report Parameter is created, its AutoSearch properties can be used to automatically create AutoSearch criteria to update its value. See the following article on the fundamentals of Report Parameters.

https://rbwiki.digital-metaphors.com/end-user/fundamentals-end-user/report-parameter-fundamentals/

See the help topics for TdaSQLBuilder, TdaSQLCriteriaList, TdaSQLCriteriaList.AddParamSearch, and TdaSQLCriteriaList.AddAutoSearchWithParam for more information and examples.

2. The black background icons are caused by the Application Manifest Runtime Themes not being enabled. This is enabled by default for new projects in Delphi but likely needs to be enabled for your older application.

Select Project | Options from the main Delphi menu and then select Application | Manifest. Inside that dialog, be sure the "Enable Runtime Themes" option is enabled.

DTWaling

Great!
That wiki article (as well as the two sample projects it links) happens to be the one that lead me down this path. So, it seems I am going in the right direction. And the added clarification helps too.

WRT the icon issue, I did try that out and it did in fact resolve my issue.


Thanks again, this has been greatly appreciated!