Pipelines visible of several datamodules...
Hello,
maybe someone can help with this one.
We have several datamodules, (with on every datamodule a report, datapipes,
a designer, ....)
When several datamodules are created I see the datapipes of all the created
datamodules.
Actually a want to see only those pipes of the 'active' datamodule.
I know, I can use the visible property, but changing all the modules and
code is a very hard work.
Is there a simply and easy solution to solve this problem?
Regards,
Kurt Rogiers
Officinall
maybe someone can help with this one.
We have several datamodules, (with on every datamodule a report, datapipes,
a designer, ....)
When several datamodules are created I see the datapipes of all the created
datamodules.
Actually a want to see only those pipes of the 'active' datamodule.
I know, I can use the visible property, but changing all the modules and
code is a very hard work.
Is there a simply and easy solution to solve this problem?
Regards,
Kurt Rogiers
Officinall
This discussion has been closed.
Comments
The only way to prevent ReportBuilder from displaying the pipelines in the
report designer is to set their Visibility property to False. This should
just be a one time process of selecting each pipeline in your project and
setting visible to false in the Delphi object inspector. Note that it is
possible to mulit-select each pipeline and set the Visible property to save
time.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Maybe a have to ask my question in a different way!
Here's an example.
TLabel = Class (TDatamodule)
- Report
- Designer
- Serveral datapipe's
TLabelProduct = Class (TLabel)
- specific datapipes for labelproduct
TLabelPatient = Class (TLabel)
- specific datapipes for labelpatient
If we create a TLabelProduct and a TLabelPatient there are 2 designers and 2
reports in the air.
If I'm design the TLabelProduct-report, I don't want to see the pipes of
TLabelPatient and visaversa
but a do want to see the pipes of TLabelProduct.
Regards,
Kurt Rogiers
Officinall
Thanks for the clairification. Unfortunately in your case, you will need to
manually assign the visibility of each pipeline you wish to see or ignore.
Another direction you may want to explore is to keep all your data access
local to a saved report template using DADE. This would remove any need for
multiple datapipelines as they would be dynamically created once the
template was loaded. Also, only the datasets local to the template will be
visible to the user at design time.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
We changed the source so that only the current forms is searched and all
datamodules (which holds global pipelines). Maybe you should also change the
source.
Gruß aus den Bergen
Günter
in some cases in our application we need to use the common way with
pipelines (no DADE) and now we are having the same problem... Not
understandable, how such a "problem" can exist that long without being fixed
/ addressed in some way. There should be a way to control the availability
of data origins (forms, datamodules) and pipelines in a report. In the case
of several datamodules the advice to set pipelines as invisible appears as
not very serious, to be honest...
Now, after 2,5 years since the last reply here the chance to get an other
reply is probably low, but I will try it...
What has to be changed in order to get it working better /
developerfriendly?
An other question:
in the DataTree I have the name of my DataModule visible, following by the
pipelines. While I can control the visibility and the caption (username) of
the pipelines, I don't know how to do it for the DataModule itself.
I found this article in the rbWiKi:
http://www.digital-metaphors.com:8080/index.php?title=End-User/Designer/How_To...Refresh_Data_Tree&highlight=data+tree
Though in the example there there is no such Node in the DataTree, i.e.
pipeline only, not matter if I say
lDataTree.TreeView.ShowRoot := true;
or
lDataTree.TreeView.ShowRoot := false;
Depending on the value I *would like* to have, the DataTree *does* already
have that value before the code is executed. However: there is no change.
Also I didn't find a way to access the root to set the caption or so:
lDataTree.TreeView.Items.GetFirstNode is the first pipeline in that example.
Kind regards,
Mark
An enhanced way to control the visibility of the pipelines available inside
the report would be a nice feature. We base the decision of many new
features on user feedback and I will add this to the list of possible
enhancements for a future release.
Currently, using DADE exclusively is the more developer-friendly option .
I'm a bit unclear about what you would like to see happen in the Data Tree.
It is designed to organize all data components based on which form/data
module they reside in. It is possible to alter the caption of the
datamodule by changing the Name property.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
thanks for your reply!
That would be nice, thanks for considering this!
I noticed already, that you guys love DADE
That's indeed a really great feature and your comment is surely true in
general, but as I said: unfortunatelly in some cases we can't accomplish
with DADE everything we need (seem not to be able at least). So we are using
memtables here, which are placed on several DataModules and are getting
filled within our classes etc. Different languages do play a role too and we
often need different fields (Description in language 1, Discription in
language 5 etc.) coming from the same join and so on. We also need to get
data from several tables to certain IDs and these IDs are known only *after*
some "higher-level" datasets (where those IDs are stored) got opened etc.
That's the problem (from my point of view): the Data Tree shows *not only*
the pipelines based on which form / datamodule the report / designer resides
in. It shows me pipelines form two *different* modules. That's my problem
An example:
=========
I have an overview of all the reports I have created. They are showed in a
grid with some data like name, creation date etc.. Below the grid there is a
preview in a panel, which shows the currently selected report. This overview
and preview are based on a datamodule with some queries, memtables and
pipelines to show the data.
From that overview I can click on a button and open a form, where I can edit
the data of that selected report, some additional options for it's usage
within the application etc. I also can edit the report itself here in a
designer. This form is based on a datamodule as well, but on a new one. It
contains similar pipelines to show the same data as in the overview, but
those pipelines are based on different memtables, since - as I said - the
datamodule is a different one too. And so I see both datamodules in the
designer, although the form is based on the second one only.
I tried to make one datamodule which does / contains what I need and to
create two instances of it once I need them, but the result is the same: in
my form (in the data tree) I see the datamodule of the form *and* the one
from the overview incl. the pipelines. So two nodes for each datamodule with
the same pipelines for each of them.
If I set the pipelines of the first datamodule to visible := false, then I
see only one datamodule in the designer, but that's somehow "dirty"
And also not understandable, why it is that way.
In the designer I see a rootnode (or two in the example above) and then the
pipelines of each root. The rootnode has the name of my datamodule. In the
example above "DataModuleX" and "DataModuleX_1".
Renaming the datamodule is not that good, since it wouldn't meet our naming
rules anymore. Also it would have to be in different languages. So I either
need a way to hide the rootnode and to display pipelines only or to access
and rename the rootnode in the data tree only.
In both cases I can't find a way to accomplish it (if it's possible).
Hope that makes it more clear
Mark
How so? What would you like to see instead? Any suggestions you might have
to improve this aspect of the product are greatly appreciated.
Try indexing directly to the node you would like to alter. In my testing,
with code similar to the example you mention, the following code
successfully changed the caption of a datamodule node...
lDataTree.TreeView.Items[0].Text := 'My DataModule';
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Hi Nico,
I probably did describe it not that well. I mean that it is already not
understandable and "bad", that several datamodules (+ pipelines on them) are
visible in the data tree, despite the fact, that those datamodules don't
have anything to do with each other. Because of this behaviour there is need
for solutions like hiding the pipelines of the first datamodule when
creating the second one and to make them visible afterwards again, which is
not a fine solution for such a case in my opinion, since this case shouldn't
be possible in the first place - again, in my opinion. That's what I meant
So my suggestion would actually be, that only pipilenes from the form /
datamodule, where the report & designer are placed, are showed. Or a way to
assign datasets / pipelines to a report (like in FastReport). But that's
something you alrady mentioned as a potential feature for one of the next
releases.
I will try this out, thank you!
Regards,
Mark
Thanks for the feedback.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
I tried this now and it isn't working for me. When debugging, I see that the
changes actually happen, but I don't see them in the TreeView afterwards.
Not even if I try to refresh / rebuild it. I treid all this in different
orders / combinations, but without success:
lDataTree.TreeView.ShowRoot := false;
lDataTree.TreeView.Items[0].Text := 'test';
lDataTree.TreeView.TopItem.Text := 'test';
lDataTree.TreeView.Rebuild;
lDataTree.TreeView.Refresh;
Before lDataTree.TreeView.TopItem.Text := 'test'; I see the name of the
DataModule in the Text-property, it's changed once this row is executed, but
not in the TreeView. Don't know what the reason is. Maybe the problem with
the 2 datamodules described above?
The name I see in the text-property is not exactly the name of the
datamodule. A "_1" is added to the name, but on the other side that's also
the name I see then in the TreeView, so actually it should work.
Something is wrong here...
Mark
I'm not sure what is happening in your case. You might try creating a
simple example application like I did and see if you can get that working
first. This may give you some clues to what is happening in the more
advanced environment.
My example consists of a form with a Report and Designer. A DataModule with
two pipelines. Code inside the Designer.OnShow to alter the Text property
of the first node in the tree.
lDataTree.TreeView.Items[0].Text := 'My DataModule';
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
DADE is open and extensible.
You can build custom DataView classes to do anything that a TDataModule can
do. A TDataModule is a container for data components. Likewise a DataView is
a container for data access components.
You can create custom dataview templates that act like hard-coded
dataviews - they register themselves with DADE and appear in the New..
dialog within a Templates tab. You can also create custom dataviews that
have custom data designers - this is how the RB QueryDataView and it's
associated QueryDesigner and QueryWizard work.
Check out Demos\EndUser\Custom DataViews for examples.
For an overview of the architecture see this article
http://www.digital-metaphors.com/rbWiki/DADE/Fundamentals/DADE_Architecture
Also see the architecure diagram, not the Custom box
http://www.digital-metaphors.com/rbWiki/DADE
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
The Delphi architecture of the TDataModel is such that it is global/visible
to the entire application. The reason RB works the way it does is because
customers requested that we follow the Delphi standard. If you place a
Report on a form and place some data access components on a DataModule, then
customers want the ability to connect to that data.
If you want to use DataModules and want to keep things clean and efficient,
then I recommend creating instances of a DataModule only when you need to
generate a specific report. And then free the Report and DataModule
immdediately afterwards.
You can also set DataPipeline.Visible to False to hide datapipelines.
Lastly if you wan to customize the way the DataPipeline list works, you you
can easily modify TppDataPipelineList in ppDB.pas. Check out
TppDataPipelineList.BuildListRunTime, you just need to modify that method
not to iterate thru the datamodules.
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
the keyword was "code inside the Designer.OnShow". I was doing it *before*
Designer.ShowInPanel all the time, since I thought, that the designer can be
prepared first and then just showed afterwards. Seemingly "OnShow" sets all
these values again.
I also tried it *after* Designer.ShowInPanel earlier and it didn't work
either, but htere must have been an other issue, since it works afterwards
too.
Thank you for your help as always!
Mark
That makes sense of course and I agree, that this should be possible, but
there should be a way to determine, what DataModules / Pipelines should be
available for this at all. In our application we have one DataModule per
Form / Frame to keep it clean. Additionally there is a MainDataModule. This
one is for the entire application, all / most others are responsible only
for the appropriate Form / Frame.
In the case I described we have an overview with all created reports. It's a
frame with a DataModule behind it. To be able to preview the selected report
there are pipelines on that DataModule. So far everything ok. Now the user
can select a report and open an Edit-Form to change the report. Again: this
Form has it's own DataModule and to show the report / designer pipelines are
needed and are placed on the DataModule. It's a modal window at that moment,
so actually an other level / layer / whatever and both don't have anything
to do with each other at that moment
I also tried to create a DataPipelineList and to add pipelines manually,
which would be enough, but it doesn't work. In the end the same 2
DataModules a 3 pipelines are available in the designer.
That was one of my first thoughts, but in the case described above it
doesn't make sense / wouldn't be efficient. I need the DataModule in my
overview before I open the Edit-Form to change a report and after I do that.
After editing I only might need to reload the report, but to free the
DataModule before calling the Edit-Form and to create it afterwards again is
neither efficient nor clean in my opinion
That did work, though I'm using it not with a good feeling. It's a bit
better than to free and create the DataModule everytime, but still not that
great. Tried to explain it in the replies above already
Good to know! I tried this and it did work too. Since setting
DataPipeline.Visible to False works as well, I would rather not to change
your code because of updates etc.
All in one: I seem to have now, what I wanted to have, but I have some
concerns about the ways to accomplish that, which I hopefully presented here
well
I also noticed, that TppDataPipelineList.BuildListRunTime is called several
times instead of once, when it's needed. Just a side note.
However: thank you very much for the effort and patience! Maybe a better
solution can be found to make the handling of Pipelines & Co more
transparent and flexible.
I invested some time into getting used with DADE, since my / our last
experience with RB was with the version 9 or even 7, I believe. That
invested time is probably not enough to be an expert and to see everything
it offers, but it seemed to be not possible to accomplish everything we
needed.
It's not only the location of our queries / memtables. It's more because of
the data we need within the report. Not everything comes straight form the
database.
While it would be possible to join the tables to get the related data, we
also need "custom" flieds, which are filled at runtime and are not in the
database.
Example:
Printing of an invoice. The invoice has some "master" data like customer,
address, paymentcondition, contactperson, responsible employee and so on. It
also has some "detail" data, i.e. invoice positions.
Most of those master data are separate tables. The invoice is again an other
table and there IDs of that data saved. IDs and some other fields, in case
the customer or payment condition gets deleted, to make it possible to print
that invoce again if needed.
Our customers often wish to have more data to the customer, to the
paymentcondition and so on. We have those data in separate tables and so we
decided to hide the IDs of those data in the invoice table, but to make a
separate pipeline for each of those data, i.e. a pipeline for all data of
that cutomer (instead of only a few fields, which would be available in the
invoce table), all data of the paymentcondition, address etc.
Also the customer has some IDs to other data stored, for example the ID of
his default bankingaccount, so we want to make a pipeline for the data of
customer's default bankingaccount available as well.
So here already several data layers: CustomerID in the invoice table ->
Customer data to that ID from the customer table -> BankingaccountID of that
customer -> bankingaccount data from the bankingacocunt table to that ID and
so on.
An other case: The pipeline for the address shall have a field with the
formatted address, built from the single fields stored in that table based
on the specified format. This farmatted field isn't stored in the database
to each address. We do format it at run time and want to have this field in
our pipeline then.
That's a few examples of what we need.
DADE might make this possible or not - I don't know for sure. At the moment
we consider DADE for lists and statistics, which should work fine with the
autosearch parameters. Since we are under time pressure a bit, we decided to
work with the known system for now, but will consider DADE for later usage
(also for the complexe situation above) - especially if you say, that all
this is possible with it.
Thanks again for the help, patience and effort! Comment ahead
Mark
show the built-in preview, and then back to the designer itself, the text of
the first tree-entry is set to the name of the datamodule again.....
Why should the treeview be rebuilt again during this process? How can I
react here to change the name again?
Try using the OnTabChange or OnTabChanged events to determine when the user
is moving back and forth from the preview to the designer.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
OnTabChanged did work. Still had to remove the refresh-popupmenu of the
DataTree, since after refreshing the DataModule-name was showed again, but
now it's ok.
Thanks for your help!
Mark
unfortunatelly there is an other case, where the name of the DataModule is
used again:
if I hide the DataTree via the mainmenu and then show it again...
I tried to use the lDataTree.OnVisibleChanged event, but it doesn't fire.
Also other events (of lDataTree.TreeView as well) didn't lead to a success.
How do I accomplish that?
Mark
You could possibly use the OnClick event of the menu option used to show or
hide the Data Tree. I believe this menu item acts as a checkbox so it would
be possible to determine whether it is being shown or hid.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
that's what I figured out a bit earliler today and it works fine
Thank you!