ppTextPipeline is locked

rbuser

Subject - ppTextPipeline is locked

My program has a text pipeline.

I can assign a file to it and successfully produce a report.
Eg. ppTextPipeline1.Filename := 'FileA.txt';

The problem arises when I want to switch to another file, say
'FileB.txt'. Or write new content to FileA.

If I code
ppTextPipeline1.Filename := 'FileA.txt';
.......
ppTextPipeline1.Filename := 'FileB.txt';

or code
ppTextPipeline1.Filename := 'FileA.txt';
.......
ppTextPipeline1.Filename := '';
ppTextPipeline1.Filename := 'FileB.txt';

the file FileA is not released.

Even Windows Explorer can not delete the file.

The "ReportBuilder Demo Reports" do not have this problem. Why?
They only produce one report at a time.

I tried the code
ppReport1.Reset;
but that didn't work either.


What do I have to do to unlock the pipeline?


Regards, Peter Evans

nicocizik

Hi Peter,

I tested this with the latest version of ReportBuilder... Version 7.03 and
the initial file was released when I changed the filename of associated with
the TextPipeline. Be sure you are using the latest version of
ReportBuilder. If you would like to see where this file is set in the RB
code, please see the ppTxPipe.pas file, in the TppTextPipeline class.

--

rbuser

Nico Cizik,

Thank you for your assistance.

with

I believe I am using Version 7.03.
I will double check though.

Regards, Peter Evans

rbuser

Subject - ppTextPipeline is locked

Nico Cizik,


Thank you again for your assistance.

I have now rechecked. I am using Version 7.03. I have checked the
installation log.
This is from the log ::-
"Title: ReportBuilder Professional 7.03 (Trial)"

I also see at design time that same Version. This is what appears ::-
"Demo Copy - Version 7.03"

As I have the trial I do not have the source so can not see 'ppTxPipe.pas'.

I am struggling to understand the flow of events in this component.

Fortunately I do not need the source code to follow the events.

I instrumented my test program with debug statments.

Here is the code for the event OnOpen and OnClose ::-

procedure TRpt.ppTextPipeline1Open(Sender: TObject);
begin
inherited;
{$IFDEF DEBUG}
OutputDebugString(PChar('Report - pipe Open'));
{$ENDIF}
end;

procedure TRpt.ppTextPipeline1Close(Sender: TObject);
begin
inherited;
{$IFDEF DEBUG}
OutputDebugString(PChar('Report - pipe Close'));
{$ENDIF}
end;

This is very straightforward code which simply outputs when the events fire.

This is from the event log ::-

ODS: Report - pipe Open
ODS: Report - pipe Open
ODS: Report - pipe Open
ODS: Report - pipe Close


This simple output demonstrates that the Pipeline opens 3 times before it is
closed.
There is only the first assignment of a file to a Pipeline. Please note that
the Close takes place when the ReportBuilder components are destroyed.


When I switch Pipelines the output is exactly the same. Put another way, the
component
does not Close or Open the Pipeline.

It is quite simple to demonstrate that. Place one debug statement prior to,
and another
after a file assignment.

The only way to get it to work is to manually code a Close statement.

This seems to be a problem with the ReportBuilder pipeline components.
Please let me know Digital Metaphors position on this question.

However there is still the fundamental drawback of there not being matching
Open and
Close pairs. This means that it is not possible to write code in the Open
method and
reciprocating code in the Close method. The purpose and intent of such
methods is to
provide the developer with a sound foundation for their own program
development.
The developer relies on the component vendor to have rock solid code that
operates in
a dependable way. Currently the components do not do this. Please let me
know Digital
Metaphors position on this question.

Regards, Peter Evans

nicocizik

Hi Peter,

After further testing I was able to see the file locking problem. A
datapipeline is not closed when the report is, although sometimes it
probably should be, we leave it up to the developer. As you said below,
this can (and should) be done manually, perhaps in the
Report.PreviewFormClose event.

I was not able to recreate the issue of the TextPipeline opening multiple
times but through a little research, I was able to determine that during
report generation, it could be possible. We do however have code inside the
TextPipeline class that checks for this and essentially causes the
application to ignore these calls. The same goes for calling
TextPipeline.Close multiple times.

As a Digital Metaphors engineer, I can assure that the ReportBuilder code is
very solid however if you ever do find an issue, we will work to resolve it
as quickly as possible. This is one of the reasons our support is only done
by our developers. Being a software developer yourself, you know that no
code is perfect but rest assured, we're working on it :-).

--