Important questions before making a decision

rbuser

Hello,
we need to clarify a few more things before we can make a decision, if
ReportBuilder is the right solution for us:

1) Will it be possible to zoom within the designer / workspace soon / at
all?
2) Will it be possible to determine, which paper trays different pages shall
be printed on? I read that it is somehow possible by code, if I'm not wrong,
but most other solutions do support this feature by default.
3) Will it be possible to work with dialogues within the reports? So the
user can create one, which either works as an InputQuery or checks some
fields and asks before printing, if the report shall be printed, even if
some certain data is missing.
4) Will it be possible to work with nested datasources, queries, tables
etc.?
5) Is it possible to see somewhere, what changes are planned for the future?

Thanks in advance,
Mark.

nicocizik

Hi Mark,

Thanks for considering ReportBuilder!

1. This feature is currently on our to-do list for a future release.

2. You are correct, this is possible in code. It is a very simple
solution. See the following article on how this can be done.

http://www.digital-metaphors.com/rbWiki/Output/Printer/Control_Bin

3. ReportBuilder contains the AutoSearch feature which gives the user a
dialog to filter the data retrieved. Take a look at the AutoSearch demos
located in the \Demos\5. AutoSearch\... directory and in the End-User
application demos \Demos\3. End User\...

4. This is also possible in the data workspace. It is possible to link
multiple tables or queries into master/detail relationships as well as join
multiple tables. Subselects are also supported by DADE. What exactly did
you have in mind for your application?

5. We do not publish a list of upcoming features however we take all user
requests very seriously and encourage suggestions and comments.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,
thank you for the info!

To 1)
It acutally doesn't help to know, that a feature is planned for one of the
future realeses, since it can be in 5 years or something like that, but the
ability to zoom in general is not an absolute key feature (for us), so we
would be able to live with that. Of course the sooner it's available, the
better

To 2)
The problem with the suggested solution is that the developer has to do it
by code, especially since he needs to create the settings-dialogue for the
customer within the application first. Also those settings aren't saved in
the report as far as I understand it, which is not good also, because
different people have different requirements for this type of settings.
Some other solutions offer the ability to determine paper bins by default
(partly even per page), which is nice. Maybe you can add this as a feature
request

To 3)
Not sure if I described it well. I think here we should differ between three
parts:
a) InputQuery for let's say the caption of a label or to execute an action.
Before print / preview the dialogue appears and depending on what the user
typed in or clicked on, a text gets changed or an action is executed.
b) Similar as the point a: before printing a field needs to be checked and
if it's empty or so, a message appears, where the user can determine, if the
report shall be printed anyway, not printed or if the current action shall
be canceled (yes, no, cancel)

I can't see this feature in the AutoSearch-samples, so the question is, is
it possible and how?

There are more examples for the third case:
c) the ability to control the data within the report (QueryParameters). This
looks good and can be usefull.

In all three cases there are some basic problems, though:
Those dialogues need to be coded at design time and complied with the whole
application, if I see that correct. So the end-user has no chance to design
a dialog on his own, because the dialogue is hardcoded in our project. We're
searching for dialogues which can be stored with the report file and can be
accessed via RAP.

We would like to have the ability to determine all this per report, not per
application. If an end-user wants to have an additional dialog for himself,
it doesn't mean, that all other end-users want to have that dialog as well.
Or he wants to see a certain data in the report, he might need his own
QueryParameters + dialogue. We could also create such user-reports and send
them to certain customers, but not to all.

The interaction with the end-user is necessary (can be wished, can be not
wished).

So the question is, what to do here and how?

One possible solution could be to place the code from those
AutoSearch-samples within the report (if possible). This would allow to use
those InputQueries and other dialogues report specific.

One more problem is the data for InputQueries. In all the
sample-applications the parameters are for a table / query, which is placed
on the Delphi form and _not_ within the report itself. This is problematical
as well, since the control of the data needs to be coded and compiled with
the whole application.

Here we come to point 4, actually, since that's what we had in mind mainly.

To 4)
I had some difficulties to understand this part, but it looks like the data
that's available within the report is ODBC based only. Is that right?
We work with a Firebird database and would like to have the ability to
access our database or certain tables / fields directly from the report, so
we can then make use of those InputQueries more flexible and again:
user-specific / report-specific.
Either we need direct access with the ability to select those tables /
fields or the ability to insert a IBOQuery (which we are using) or an
interface to it, so we can access the data via SQL only.

Hope that explains a bit better, what we have in mind.

Thanks for your time,
Mark.

nicocizik

Hi Mark,

2. This is not a built-in feature however I can see how it could be useful
and we will consider adding something like this to a future release. In the
meantime you would need to perhaps replace the current print dialog and add
the feature yourself. The nice thing about ReportBuilder is that all
dialogs (with the exception of the designer) are completely replaceable
making customization very easy.

3a. ReportBuilder 11 includes autosearch parameters. This allows you to
create a report parameter, require that your user enters a value before the
report prints, and then allows you to do what you like with it in RAP, DADE,
etc. In your case you would have your user enter in a value for the
parameter, then in RAP code you would assign the label value to the value of
the parameter.

Label1.Caption := Report.Parameters['MyParam'].Value;

3b. When there is no data for a pipeline you can use the Report.OnNoData
event to customize what the end-user sees. See the help topic on the
TppCustomReport.OnNoData for more information with using this powerful
event.

3c. The autosearch dialogs are part of the product, so there is no need to
"code" them unless you would like to create custom dialogs (in which case
they can be included with your application). Though the autosearch examples
use Delphi to filter the datasets, it is more likely that you will simply
use the Autosearch features built into DADE so there is no need for Delphi
code. If for instance you are creating a query in DADE (data tab) using the
Query Designer, you can move to the Search tab and create various search
criteria. Then by simply clicking the "AutoSearch" checkbox, an Autosearch
field is created and the dataset is automatically filtered without any
Delphi code needed.

You are correct in that the end-user designer does not allow the creation of
custom dialogs from within RB. It is however possible to create custom
dialogs and access them via RAP code. Take a look at the RAP demos for
examples of this as well as implementing RAP pass-thru functions which are
also very useful.

4. The data access architecture is not limited to a certain connectivity in
ReportBuilder. We have numerous customers using Firebird successfully with
IBO. Using the IBO plug-in located in the \Demos\4. End User
Databases\Interbase\IBO\... directory, you can easily create queries in the
data workspace that are local to and saved down with the report template.
It is also possible to edit these queries manually if you would prefer to
create your queries by hand however this prevents you from using the Query
Designer to alter the query in the future (for that specific query).

Let me know if you have any more questions or if you need any more
information on what was mentioned above.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,
I fear not everything is clear yet to me, sorry.

2.
Sounds good. To replace the current print dialog and add the feature myself
could be an option, but it would be not that practicable, since the user
would have to set those options everytime he is printing different reports.
Ok, we could store the settings maybe...
However: how can the dialogues be replaced in general? Are there any
examples about it? Somehow I'm loosing the overview a bit at the moment

3b.
Here I meant something different.
One of the examples: our application will have some fields, which users can
use individually, if they wish to. One user might need them, an other might
not. To make it possible for the users, to use those fields and to check the
content of them before printing, we would like to have an ability to create
/ use dialogues within the report. Because of the individual usage we can't
create those dialogues within Delphi, since not everyone needs them. Even if
we would do it and prepare some common dialogues, we would have to compile
the whole application completely everytime an user needs a new dialogue.
That's what we want to avoid.

That's also the reason for the following questions of

3c.
Even if Delphi code is not needed, the datasets (at least in those examples
you mentioned) are in Delphi, not in the report, so by doing it that way we
would have to adjust / compile the whole application again, once a change is
needed.

Here you said though, that it's possible to use the Autosearch features
built into DADE, which is good.

But as far as I see, I can only _access_ custom dialogues via RAP, if I have
them as Delphi forms in my application. I didn't see anything in the
examples, where custom dialogues are _created_ with RAP. Did I miss
anything?

Or do you mean, that the Autosearch features could be used for all those
needs? If so: how can a dialogues be created, which contains a hint, that
the field "ABC" is empty and a question, if the report shall be printed
anyway with 3 buttons (yes / no / cancel) and how to react to the result of
that dialogue (click on one of those 3 buttons)?


4.
Unfortunately I can't execute the project in "\Demos\4. EndUser
Databases\InterBase\4. IB Objects\". It seems to be for Interbase only and
do not work with Firebird server installed. I'm getting an error, that the
ODS 11.2 is found in EMPLOYEE.GDB (which can't be for real, since ODS 11.2
is supported with Firebird 2.5 - available only as a beta so far). Even if I
install a beta version of Firebird 2.5, the error is still there, though it
says "ODS found: 11.2; ODS supported: 11.2". So actually it should be ok
according to the versions, but it still isn't working.

Regards,
Mark

nicocizik

Hi Mark,

2. Sorry, this was just a suggestion. There are many ways of going about
this. What did you have in mind for a more practical way of doing this?

All dialogs and forms in ReportBuilder have an ancestor class located in the
ppForms.pas file which then descends from the TppForm class. To replace a
dialog, you can simply copy the existing one, rename it, and register it
using the form registration routine ppRegisterForm. If you take a look at
the initialization section of the ppPDlg.pas file you will see how the
current Print Dialog is registered.

A tutorial of ths can be found in the \Tutorials\Complete\II.
Applications\04. End-User with Custom Explorer\... directory.

3b. Unfortunately the ability to create new dialogs solely in ReportBuilder
is not a feature. The best option here would be to create a number of
"canned" dialogs that may be used by your customers and instantiate them as
needed. Another would be to write a dialog creation utility that could
dynamically create a certain dialog based on the user specifications (that
you provide).

3c. Sorry if I was unclear about this. In my first reply I mentioned that
in addition to taking a look at the AutoSearch demos located in the \5.
AutoSearch\... directory, you should also take a look at the EndUser demo
located in the \3. End User\... directory. Once you run this demo, you
will have access to reports that use the AutoSearch feature however do not
use any Delphi code and no datasets, pipelines, etc. are located on the
form. You can use the AutoSearch feature completely separate from Delphi.


This is correct, dialogs cannot be created in RAP, they must first be
created in Delphi then used in RAP.

4. The IBO plugin simply uses IBO components to connect to your data, it
should not matter which DB you are using. Note that by default it tries to
connect to the Employee.gdb database however it is necessary to create the
proper tables rbItem, rbFolder, rbTable, rbJoin, in order for the end-user
app to run correctly. See the ReadMe.doc file.

It is not necessary to run the example to create IBO queries from within
ReportBuilder. At runtime you can simply add the daIBO file to your uses
clause to register the plugin, then from the data workspace you should be
able to connect to an IBOConnection and create queries as you need.

I highly suggest you spend some time working through the DADE tutorials
located in the Developer's Guide so you can gain a stronger understanding of
how this part of the product can be used.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

nardmoseley

1. Paper Trays

The Report.PrinterSetup property can be used to control the paper tray. If
you want a single report to print to multiple trays, you can use Subreports
set to PrintBehavior pbSection. Each 'Section' can reprsenent a page.
Section subreports can have their own PrinterSetup properties that are
different from the main report. They can even print as a separate print job
to a different printer.

2. Dialogs and Extending RAP

If you need to define and use custom dialogs, I recommend extending RAP with
some custom utility functions that accomplish what you need. One of the most
powerful features of RAP is that you can easily extend it with custom
functions.

http://www.digital-metaphors.com/rbWiki/RAP/Extending_RAP/Overview






--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Hi Nico,

2.
No need to say "sorry". It wasn't meant as critique or so
Each suggestion helps and show new options. I was just thinking loud and
compared it with the solution, which I mentioned as a feature request
earlier (where you agreed to as well). Compared to this the last suggestion
is less practical, but still a possibility, so keep suggesting / commenting
please


3+4.
Thank you for your hints and advices to this part. It wasn't that clear
before your last reply, what sould be done and that all this is available /
possible at all, sorry.
I was able to use the IBO-Plugin for DADE now, tried a few things with it. I
also did some experiments with the AutoSearch-feature and with the custom
functions added to RAP module to show some custom forms or dialogues. That
covers questions 3 and 4 I had.

Most questions about this part are more or less clear now, I think, though I
have some new, which follow now:


3a.
I'm testing all this on a virtual machine at the moment. At least there I
have an issue with the DataView classes when trying to open a project, which
contains them. The message "Class TdaIBOQueryDataView not found. [...]"
appears (for each DataView I have). When I click "cancel", the project isn't
loaded and I'm getting this message everytime I try to open the project
next. Once I click on "ignore" and my project is opened (without the classes
/ DataViews), I can close it and the next attempts to open it are all
successful as long as Delphi is not restarted.
Any idea what is wrong?


3b.
Within the Query Designer all tables of my database are available and so are
all field of each table. I would like to have the ability to show certain
tables / fields only, since the user may not see everything.
Exactly this seems to be accomplished with the custom dataview templates,
right? They are defined by me and are just added in the form how I defined
them.
Is it correct to say, that they are the same as the result of the Query
Designer just with the difference, that I do define them in one case and the
user does define them himself via the Query Designer in the other case
through accessing all the tables and fields?

If so, then I see two "problems" here:
- In that case I would have to add as many custom dataview templates as I
want to make visible to the end user and the same for fields per table. This
would still be ok, though what about the AutoSearch criteria? What about
parameters?
I added the units myDataVw, myQueryDatavw and dvDesign from the example
project to my project and even if I set the "searchable" parameter for the
"AddSelectField" procedure, I still see that dialogue from dvDesign with
only 3 fields for search and 3 fields for sorting (without labels, btw.).
What am I doing wrong?
Luckily I found out then, that it seems to be possible to use the same
dialogue, as it is in the Query Designer, where all this can be defined
easily (also parameters) by using myQueryDatavw.

Well, at least I see the defined fields from that certain table in the new
DataView, but I can't click on the button "tables", since an error occurs
(Unknown database Alias: IB_Connection1 [...]).
Also I wanted to remove some of the fields in "procedure
TdvCustomerQuery.DefineSelectedFields;" to see, if I really can determine
them and here I get an error "Engine-config file not found [...]".

I don't know what I am doing wrong, but I don't find a way to check those
last few things out.

- If the first problem can be solved somehow and custom DataView templates
are really the way to go, if I want to allow access to certain tables /
fields only, then there still has to a possibility to "remove" / deactivate
the "full" Query Designer / Query Wizard, so the user don't have access to
all the tables / fields.

How can this be done?


3c.
If I have a DatePipeline on my Delphi form and have some DataViews within
DADE, I see them all in the DataTree on the designer page, but the Pipeline
is not available in DADE, so I can't use the AutoSearch feature for it *from
the report*. Sure, since the pipeline is on the form, the DataSource and
DataSet will be there as well, so it's possible to create the AutoSearch
fields in Delphi, but I was just wondering, if there is a reason, that the
pipelines aren't available in DADE. It could make sense to use them there as
well.


3d.
Within the Query Designer it's possible to use parameters. Values for them
can either be requested via those autosearch fields or be assigned directly
without the dialogue. The problem I see here is, that *all* parameters are
visible here in the combobox. This is problematical, since not all
parameters assigned to the report will be supposed to be used for the
"control" of the DataViews. There is a property "Enabled" in the
AutoSearchSettings of the parameter, though it only says, if the AutoSearch
dialogue shall appear or not. If not, then the value will be assigned
directly, which makes sense.
So actually an additional property is needed to allow to control, which
parameters shall be visible within the Query Designer.
Possible solutions:
- a per-parameter property "VisibleWithinQueryDesigner" (true / false)
- a per-parameter property "ParameterType" as a combobox ("ReportParameter"
and "AutoSearchParameter"). After selecting of the second,
AutoSearchSettings become available
- two different parameter lists "ReportParameter" and "AutoSearchParameter"

In my opinion this is important and should be possible in some way.


3e.
As far as I see, the operators within the Query Designer are not complete or
the descriptions of the autosearch dialogues are not correct.
Example: I create the following searchfield: "PHONE_NO like '234'".

The SQL shows "[...] WHERE (CUSTOMER_1.PHONE_NO LIKE '234%')" and the
AutoSearch dialogue says "[...] PHONE_NO starting with 234". Both is not
exactly what the "like" operator means, I think. Here the "starting with"
operator would be better.

While it's possible to accomplish the correct "like" criteria at least
within the Query Designer -> "PHONE_NO like '%234%'" so the SQL says "[...]
WHERE (CUSTOMER_1.PHONE_NO LIKE '%234%')", the AutoSearch dialogue still
says "[...] PHONE_NO starting with %234%", which is not correct and is
irritating for the end user, I think.

Maybe somehting can be done here too.


3f.
It would be nice, if the Query Designer would store the column widths or
adjust them to the content automatically.


4.
As I mentioned above, I did some experiments with custom functions for
showing of custom dialogues. It worked so far, though I have one case right
now, where I still didn't find a solution.

I'm showing a question (Application.MessageBox in Delphi) via using of the
custom function I created for this. In the message I show 3 buttons: yes,
no, cancel.
The end user shall be able to look at the report in the preview without
getting this message, but once he wants to print it or so, one or several
fields shall be checked (within the report) for certain values and in case
the values are not correct, the mentioned question shall appear. If the user
says, that he wants to print the report anyway, the print dialog shall
appear. If he says "no", the printer dialogue shall not appear (or be closed
if it's already there), but the user shall stay within the preview. If he
says "cancel", the same shall happen as if he says "no", but additionally
the preview shall be closed.

So I have my custom forms / dialogues in Delphi and call them via those
pass-through functions as you suggested, but I need to handle the result of
this within the report and in that case I'm looking for proper events and
methods to do so.

How can this be done?


5.
ReportBuilder seems to not to offer a Thumbnail-Preview as FastReports or
other products do. Did I miss anything here or is this feature not
available?
If it isn't: it's a very usefull feature and it would be nice to see it
implemented soon.


6.
Also I don't see a possibility to scroll the ppViewer placed on my form /
frame. Within the default previewform it's possible, though.
Why not in ppViewer as well?




Sorry for the length of the message,
Mark

rbuser

Thanks Nard,
I will take a look into this option for paper trays.

Other than that: I just replied to Nico's message about other "issues" /
questions. And point 2 is handled there as well.

Mark.

rbuser

An addition to 3c:

I tried to work with TdaIBOQueryDataView afterwards instead of the
TdaBDEQueryTemplateDataView, which is used in both units I copied from the
demo project.

Both classes are different. There are no procedures like
"DefineSelectedFields" in TdaIBOQueryDataView etc.
Do I have to add all this manually or does the IBO plugin work different
than the BDE plugin (aside from specific differences between BDE and IBO)?

Also: the ReadMe.doc file says something about "daIBODB.pas", which is
supposed to be located in the ..\RBuilder\Demos\EndUser
Databases\Interbase\IBO directory.
I only see the "daIBO.pas" there. Is the ReadMe file not correct or am I
missing an unit?

nardmoseley

3a. Error message "Class TdaIBOQueryDataView not found"

This error indicates that IBO-Plugin for DADE is not present. If you are
testing at run-time, you need to include daIBO in the uses clause of your
application. If testing at Delphi design-time, the relevant package must be
installed. Also note that the newer Delphi IDE's have optimized package
loading that has to be overridden to force the IDE to always load the
plug-in. This required us to re-design the plug-ins. I just checked and the
IBO plug-in has not been updated. See RBuilder\Source\dclRBIBExxyy and
rbIBExxyy packages as an example.

3b. Control which tables and fields are displayed by the Query Designer.

Use the TppDataDictionary component to control this. See the EndUser
Appilcation tutorials section of the Developers Guide. Also see the
Demos\EndUser\AutoJoin example. You can define which tables and fields are
visible and assign user-friendly aliases. You can also pre-define common
join/linking conditions.

3c. Two different types of data access: External DataPipelines that reside
on a form/datamodule and DADE.

These are two completely different approaches. DADE is a RAD solution for
managing the query building, autosearch, and also master/detail linking. Use
DADE.

Within DADE you build QueryDataViews. The QueryDataView has a TdaSQL object
that generates the SQL text command. The QueryDataView internally creates
and manages the DataPipeline/DataSource/DataSet.

With external DataPipelines you have to manually generate your own SQL,
manually define your own AutoSearch fields. For an example see
Demos\AutoSearch.

To hide External DataPipelines from the report designer set
DataPipeline.Visible to False.

3d. Optionally hide Parameters from the Query Designer

Thanks for the feedback. Might consider for RB 12.

3e. AutoSearch Like operator.

This is working as designed. To change it would break thousands and
thousands of existing reports. The autosearch description and SQL generation
are consistent. It searches for 'start's with'. You are correct in that the
SQL Like operator can be used in other ways.

3f. QueyDesigner save/restore column widths for each page

Thanks for the feedback. Will add this to the list of requested features.
Currently only the size of the form is save/restored.

4. Control whether user can print from Preview form

Slight re-ordering of what you describe, but one option would be to use the
Report.OnPrintDialog close event to check whether the user pressed 'OK'
button. Then display your dialog and take action accordingly.

This example code would prevent the user from ever printing. When the user
presses OK, this code overrides the PrintDialog.ModalResult to act like
Cancel was pressed.

if Report.PrintDialog.ModalResult = 1 then
Report.PrintDialog.ModalResult := 2;

If this is something you want to do for many of your reports you could
create a custom Preview Plug-in (see your question 6 below) and override the
Print method which is called when the user pressed the Print button.



5. Thumbnails / Outline TreeView / Text Search / Email

Rather than thumbnails, RB has a different, but very useful navigation
feature. There is an Outline feature which can produce a treeview of nodes
that contain either pages or captions with group information. From the
Report Designer select Report | Outline Settings... from the main menu.
(Thumbnails is something we may add in the future. )

TextSearch is another useful navigation feature. It enables the user to
search for text within the report. See Report | TextSearch Settings from the
main menu of the Report Designer.

Email is another cool feature. See Report.EmailSettings.

6. Scroll Preview?

I do not understand the question. What are you trying to accomplish? Rather
than the Viewer, you might want to create an instance of the Preview Plugin.
Here is an rbWiki example. The Preview Plugin is a class that manages the
viewer, toolbar, and other UI elements. It is used by the built-in Preview
form and by the Report Designer Preview page. As the name suggest, you can
create a custom descendant of the preview plugin and register it for use
with RB.

http://www.digital-metaphors.com/rbWiki/Output/Preview/How_To...Preview_in_a_Panel



--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Hi Nard,
thank you for your detailed reply!

Of course I still have some questions

3a. Error message "Class TdaIBOQueryDataView not found"

Package is installed and daIBO is included. The reason must be Delphi's
optimized package loading. I checked the Source-directory and didn't found
those packages you mentioned (dclRBIBExxyy and rbIBExxyy). Might the trial
version be the reason? If so: then I can't try this out at the moment.


3b. Control which tables and fields are displayed by the Query Designer.

In the demos it was possible to control this in TdaBDEQueryTemplateDataView.
Is there a reason, why it's not possible with TdaIBOQueryDataView, so the
DataDictionary has to be used in that case?

DataDictionary and it's usage looks a bit complicated, but is probably a
question of practice.

Most important question here at the moment: what do I do, if I want to use
aliases in different languages depending on the language of my application?
Is there a way to get this working?

Then some feedback to the Data Dictionary Builder:
once I opened it the first time the column widths n the "fields" tab were
high, so not all columns were visible and I had to scroll. Once I begin to
do so, the selected row isn't in "edit-modus" anymore, but I still can edit
it by clicking on it. Once the column "TABLE_NAME" isn't visible anymore
(scrolled out of the visible area), the row can't be edited anymore. A click
on just doesn't make anything in that case. So the form needs to be
maximized, column widths to be reduced until everything is visible.
Maybe an edit form with all the options would be good.

Also: it's possible to click onto ok-button of the Query Designer, if a
table is selected, but not field. In that case an "ugly" SQL error message
appears, which doesn't say much to the user and only scares him
Maybe the ok button oculd be disabled until all needed selections are made?


3c. Two different types of data access: External DataPipelines that reside
on a form/datamodule and DADE.

Looks like I will have to use both variants.
Question1: I have a report with some DataViews where a field X and/or table
Y are used. What happens, if this field and/or table had to be deleted /
renamed in my database? Will the DataView cause an error then? Do I have to
update all reports using such DataViews in that case?

Question2: is it possible to update report using DataViews? If so: how? Can
DataViews be added / removed / changed at runtime?


3e. AutoSearch Like operator.

Isn't it possible here to at least adjust the autosearch description
depending on the way the like-operator is used?
"starting with S", if it is used like "like S%" or
"containing S", if it is used like "like %S%".

This would require much less trouble, wouldn't it?


4. Control whether user can print from Preview form

Printing and the whole case I described, was just an example. There are
surely many other cases where something like this could usefull.
In general it's about to be able to show custom forms and dialogues /
messages (this is working), about the events which should be used for calls
of those custom forms / dialogues (this is partly clear) and about the
methods to use to execute certain actions (cancel printing, close the
preview etc.). All this from the report, not from Delphi.

In my example the printdialog would be already one step too far. I would
like to react, before it's showed and depending on the option the user used
in the dialogue either show the printdialog or not or even to close the
preview.
So something like BeforePrintdialogShow / ClosePreview or CloseDesigner
(again: from RAP).

It's difficult to describe, so it's automatically difficult for you to
reply, I guess.


5+6.
If thumbnails would be implemented, it would be nice. Othern than that all
"concerns" and questions I had those two points are covered so far with your
tip about the Preview Plugin, thanks!

One note to it: the demo project attached to that Wiki entry is missing the
TForm1.FormDestroy event (see the code in the Wiki entry), which leads to an
error when closing the preview / form.


Kind regards,
Mark

nicocizik

Hi Mark,

3a.

Yes, the source code is not included with the trail version. These files
are included with a registered version. We are constantly trying to keep
our demos up to date and I will add these files to the next release of
ReportBuilder for the IBO demo.

3b.
The TdaBDEQueryTemplateDataView is used to hard code the table/field names.
This is much less efficient and more difficult that simply using the
DataDictionary to control everything on the fly.

The IBO plug-in is not as refined as the BDE or ADO plugins in that we have
added the groundwork for these custom dataviews. The registered version of
ReportBuilder gives access to these plugins and would allow you to see how
it can be done for the IBO plugin as well. Regardless I recommend sticking
to the DataDictionary.


Yes, by using multiple DataDictionaries.

--
Thanks for the feedback on the DataDictionary. The DataDictionary is a
simplistic utility never to be seen by the end-user. It is generally meant
to be used by the developer as an easy way to determine what the end-user
sees when designing/editing a report (which is why it is not as refined as
other parts of the product).

QueryDesigner: Thanks for the suggestion, we will consider adding something
like this to a later release. Although you are correct and there should not
be any "ugly" errors shown, the QueryDesigner is primarily intended to be
used by a person that is familiar with SQL code and Database manipulation.
The Query Wizard was designed to be used by users that have no DB
background.

3c.

You should not have to use both variants. If you are altering the actual
tables in your database, you will need to perform these actions in Delphi
however as far as data access, everything that can be done on the form, can
also be done in DADE, there is no need to have pipelines on the form and in
DADE for the same application.

Question1: If you go in and change the actual table names/field names in
your database, the DataViews will no longer function correctly. This is the
same as if you had a SQL statement accessing certain fields and tables, then
you changed those names. The SQL statement (in Delphi or RB would no longer
function and would need to be recreated).

Question2: Yes, this can be done using the TdaSQLBuilder object. See the
topic in the RB Help and the following articles for examples and
information.

http://www.digital-metaphors.com/rbWiki/DADE/SQLBuilder

3e, 4, 5, 6

Thanks for the feedback. We will consider these changes for a later
release.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,
once again thank you very much for your help!

A lot of stuff to think about, but I think it looks good.

Only one last question (so far):

3b. Control which tables and fields are displayed by the Query Designer.
Here you say, that it's possible to use different languages depending on the
language of the application by using of multiple DataDictionaries.

What exatly does it mean? If we have 10 languages, do we have to create 30
tables (3 per lanugage)?

Kind regards,
Mark

nicocizik

Hi Mark,

If you had 10 different languages, you would need 10 separate
DataDictionaries. The easiest way to do this would be to place as many
dictionary objects on the form as languages you have
(ppDataDictionaryEnglish, ppDataDictionaryGerman, etc.) Each dictionary
will access the same table(s) and define the table and field aliases in
their separate language translation.

Then when a report is loaded, you can check the preferred language and
assign the proper dictionary to the designer object.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,
sorry, but somehow I don't see how this is going to work.

I tried this with 2 DataDictionaries now. But once I change a TableAlias and
/ or FieldAlias within one DD, I see the change in the other DD as well. The
entries in the tables rb_field, rb_table, rb_join are being updated instead
of being added for each DD (what I would expect after reading of your
explanation).

I don't know what I still am doing wrong, but at the moment I don't see how
this should work. Reading of the documentation didn't help

Mark

nicocizik

Hi Mark,

Are you connecting both DataDictionaries to the same Table, Field, and Join
tables? Note that each DataDictionary will need to have its own tables to
store and use separate data.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,

I'm connecting to only 3 tables in my database, which I created for the
DataDictionary usage.
As you might remember or as you can see, if you scroll down, that was my
first question, when I asked about how to use the DataDictionary. I asked,
if I need to create those 3 tables for each language I have. That would be
30 tables for all 10 languages.
Your reply was "[...]Each dictionary will access the same table(s) and
define the table and field aliases in their separate language
translation.[...]", so I thought that it's not necessary to create that many
tables, but that seems to be not correct now, right?

This would be a not very nice and practicable solution in my opinion, if the
developers have to create that many tables. That's almost more tables than
we have in our complete database

Maybe it is a good idea to add a "language"-field to all 3 tables and to
modify the DataDictionary builder accordingly, so it can define and store
the table and field aliases per language in the same table? Or something
like that...

Mark

nicocizik

Hi Mark,

I apologize, I must have misuderstood your initial query. The
DataDictionary is designed to store its information inside the "Table",
"Field", and "Join" tables created by the developer.

Thanks for the feedback. We will take it into consideration for a later
release.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico, hi Nard,
thank you very much for all your help!

Since a while your company has a new customer
While the product itself still has some weak points, most of our questions
and issues got resolved with the help of your really great support! That's
an other important factor and helped us a lot to make the decision.

Keep up the good work!

Thanks,
Mark

nicocizik

Hi Mark,

Great news! Thank you for the kind words and we look forward to helping you
in the future.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com