Home Datapipelines

Pipelines visible of several datamodules...

edited April 2006 in Datapipelines
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

Comments

  • edited April 2006
    Hi Kurt,

    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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited April 2006
    Nico,

    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


  • edited April 2006
    Hi Kurt,

    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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited April 2006
    In article <443e5284@dm500.>, Kurt Rogiers wrote:

    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
  • edited October 2009
    Hello,
    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
  • edited October 2009
    Hi 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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009
    Hi Nico,

    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
  • edited October 2009
    Hi 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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009

    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
  • edited October 2009
    Hi Mark,

    Thanks for the feedback.

    --
    Regards,

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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009
    Hi Nico,

    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
  • edited October 2009
    Hi 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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009



    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
  • edited October 2009

    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
  • edited October 2009
    Hi Nico,
    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

  • edited October 2009


    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.
  • edited October 2009
    >> I noticed already, that you guys love DADE :)


    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
  • edited October 2009
    Hm, I just noticed, that once I click on "Preview" within the designer to
    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?


  • edited October 2009
    Hi Mark,

    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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009
    Hi Nico,


    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
  • edited October 2009
    Hi Nico,
    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


  • edited October 2009
    Hi 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

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited October 2009
    Hi Nico,
    that's what I figured out a bit earliler today and it works fine :)

    Thank you!


This discussion has been closed.