Other Components in Windows Applications
A Windows application will often contain components designed to handle reporting and update processing. Usually, reports are placed inside of Report View components, and update processes are placed inside of Business Process components. Both of these component types are used in the same way that views are in that they:
- Are self-contained. They can be developed and tested stand-alone.
- Usually contain data-dictionary object structures that are connected and accessed according to the same rules used in views.
- Tend to have a single (or just a few) external access methods.
Report Views
Report View Components are based on the ReportView class. They are designed to hold a DDO structure, any visual objects required to set up and run a report, and one or more report objects. The report objects inside of the Report View can be based on a number of different classes and technologies. Reports based on the cWinReport2 class use the DataFlex Winprint-2 Report engine to generate reports.
Depending on the reporting technology used, the report may or may not use data-dictionaries to access the report data. If DDOs are not needed, they will not have to be included in your view. If you are generating reports that update your data, you are strongly encouraged to use DDOs in your report view.
Report View components have a file extension of .rv.
Business Processes
Business Process objects are objects that contain all of the logic to perform application update logic. Where data-dictionaries are used to handle rules for your database, business process objects are used to encapsulate higher-level rules and processes. An example of a business process might be an end-of-month posting and update. Business Process objects (BPOs) are built on top of and use data dictionary rules. A BPO will usually contain a DDO structure and will use the DDOs to handle all record finding and all data updates. BPOs will usually not contain visual interfaces.
It is expected that a BPO will contain one or more custom access methods (i.e., methods that you must create within the BPO) and those methods will be passed all of the information needed to run a process. A BPO may display a status panel, allow for a process to be interrupted, and update a log as it progresses. All of these capabilities are built into the component.
Business Process objects are based on the BusinessProcess class. Unlike the other components, a BPO class can either be created as a stand-alone object package component or it may be embedded within another component. This flexibility is provided to support the different ways a BPO may be used.
If you are creating a BPO that needs to be available as a resource for your entire application, you will want to create the BPO as an object-package component. This component is added once to your application in the same way that a view or report-view is added. Because it will be a sibling of all of your views, it can be accessed from any other object.
When Business Process objects are created as components, they will have a file extension of .bp.
If you are creating a BPO that only needs to be used by a single view, you will want to embed the BPO within that view. In this case, you are encapsulating the BPO within the view and hiding it from the rest of your application. An embedded BPO should still contain its own DDO structure and it should only use that structure. It should not rely on any DDOs that might be available in its parent object (most likely a dbView or ReportView).