There are two very simple and powerful techniques to extend the capabilities of RAP infinitely. These are summarized below and covered in more detail in the RAP.hlp online help. Demos and tutorials are installed to RBuilder\Demos\RAP. The tutorial text is located in RAP.hlp.
1. RAP Pass-Through Functions
These are functions that appear in the Language tab of RAP's Code Toolbox. These functions are written in Delphi and can be called from RAP. RAP's pass-through function architecture enable's developers to add new built-in functions to RAP's code toolbox.
2. Extend RAP's RTTI
RAP's Run-time Type information defines what classes and properties can be accessed via RAP. By default the published properties of any class that is registered with Delphi's RegisterClass procedure is recognized by RAP. In addition many of the public properties and methods of ReportBuilder classes are exposed.
Ok we did it. There is a strange side-effect not actually a problem It seems that RAP "sees" the "real" class we are registering. For example, our class (TILOracleQuery) has an SQL property, which is a TStrings. In the interface class we registered in RAP, SQL were a simple string, which, in our code, is assigned to SQL. Well RAP compiler doesn't compile a line like this
var aQry : TILOracleQuery; <- our interface class St : string;
begin st := 'select sysdate from dual'; aQry.SQL := St; // should be fine with our definition
RAP complains that the last line has an illegal assignment as it can see that SQL is not actually a string (the error is something like "incompatible types..")!
if we change the line in
aQry.SQL.Text := st
this compiles but obviously doesn't enter our SQL PropSetValue.
Sure we have a name clash here. We registered in RAP the same name of the actual class (TILOracleQuery). So RAP compiler seems to see the properties using Delphi RTTI beyond our interface
Our workaround was defining a SQL.Text property
(Hope it is clear .....it is quite difficult to explain with my english...)
Yes, RAP automatically knows about published properties of registered classes. RAP relies upon custom RAP RTTI classes plus Delphi's RTTI.
You can actually use a RAP RTTI class to hide the Delphi RTTI. The RAP RTTI methods are called first. If no custom RTTI logic is defined, the default behavior calls Delphi RTTI.
-- Nard Moseley Digital Metaphors Corporation www.digital-metaphors.com
Best regards,
Nard Moseley Digital Metaphors www.digital-metaphors.com
Comments
To define new Classes to RAP requires that you extend RAP's RTTI (see number
2 below).
--------------------------------------------------
Article: Extending RAP
---------------------------------------------------
There are two very simple and powerful techniques to extend the capabilities
of RAP infinitely. These are summarized below and covered in more detail in
the RAP.hlp online help. Demos and tutorials are installed to
RBuilder\Demos\RAP. The tutorial text is located in RAP.hlp.
1. RAP Pass-Through Functions
These are functions that appear in the Language tab of RAP's Code Toolbox.
These functions are written in Delphi and can be called from RAP. RAP's
pass-through function architecture enable's developers to add new built-in
functions to RAP's code toolbox.
2. Extend RAP's RTTI
RAP's Run-time Type information defines what classes and properties can be
accessed via RAP. By default the published properties of any class that is
registered with Delphi's RegisterClass procedure is recognized by RAP. In
addition many of the public properties and methods of ReportBuilder classes
are exposed.
--
Tech Support mailto:support@digital-metaphors.com
Digital Metaphors http://www.digital-metaphors.com
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
There is a strange side-effect not actually a problem
It seems that RAP "sees" the "real" class we are registering.
For example, our class (TILOracleQuery) has an SQL property, which is a
TStrings.
In the interface class we registered in RAP, SQL were a simple string,
which, in our code, is assigned to SQL.
Well RAP compiler doesn't compile a line like this
var
aQry : TILOracleQuery; <- our interface class
St : string;
begin
st := 'select sysdate from dual';
aQry.SQL := St; // should be fine with our definition
RAP complains that the last line has an illegal assignment as it can see
that SQL is not actually a string (the error is something like
"incompatible types..")!
if we change the line in
aQry.SQL.Text := st
this compiles but obviously doesn't enter our SQL PropSetValue.
Sure we have a name clash here. We registered in RAP the same name of
the actual class (TILOracleQuery).
So RAP compiler seems to see the properties using Delphi RTTI beyond our
interface
Our workaround was defining a SQL.Text property
(Hope it is clear .....it is quite difficult to explain with my english...)
Yes, RAP automatically knows about published properties of registered
classes. RAP relies upon custom RAP RTTI classes plus Delphi's RTTI.
You can actually use a RAP RTTI class to hide the Delphi RTTI. The RAP RTTI
methods are called first. If no custom RTTI logic is defined, the default
behavior calls Delphi RTTI.
--
Nard Moseley
Digital Metaphors Corporation
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
time)
I will try to reproduce (if time will permit ...) with the rb demo