There isn't a background printing example. Essentially we tried to make it as easy as possible- ie. require the report to have an owner form or datamodule and then nonot have and registration calls for report forms, templates or archives for volumes like you do for the Server Edition.
Using the main report explorer demo project, open up the form and add a TSession object and set Autosession name to true. Then in the OnLoadEnd event of the report template set Report.BackgroundPrintSettings.Enabled to true, followed by the Report.BackgroundPrintSettings.Active property. Then run the app and print a report:)
As far as ASTA, I'll have to try it. I don't have an ODBCExpress ASTA server running for RB, but I can test it with my local DBISAM ASTA RB end user server.
I understood that for the BDE but was having trouble (I got an error only with background print trying to open the join ds) when using Asta.
To clarify I use the report explorer with a dictionary both with Asta and ODBCExpress in the client. If I use ASTA then the server is actually ODBCExpress but that is not a factor in this issue I think.
First, you can't show any dialogs from a background thread without synchronizing. So, set the client datasets ShowQueryProgress to sqDontShow. Then set the client socket to ConnectAction to caUseDesignAddress and AutoLoginDlg to ltLoginNoDlg. But, even after this, I don't think that the Asta client socket is meant to run in a background thread as I get an error from their source (AstaSmartWait.pas) as it is trying to syncronize as it assumes it is in the main thread, which it isn't.
So, I surfed Asta newsgroup and found a post where Steve mentions that Asta uses sockets (not threads) and threads give you nothing in performance. Well, RB does create a socket in the background thread as it is generically coded to support any form you have with a report on it with any data access components that you want to print in the background. So, I ran across this post from Steve:
"So if your thread are using the same pipe, houston we'd like to re-direct what you are doing.
<<This comes from the call "Classes.CheckSynchronize" around line 240 in AstaSmartWait.pas
well you can try commenting it out as we just threw that in there for D6."
I also coded this in my end user project to toggle between blocking when I was playing around with this, but I don't have AstaSmartWait.pas in my version of Asta, just a dcu, so I don't know if this would help:
I commented out the "Classes.CheckSynchronize" and it then does connect (although the comment references D6 which is what I am using).
I am printing to a file (pdf with waler) and it starts and returns to the designer but shortly it locks up and the file stops being updated. I have tried blocking/nonblocking in the thread with no luck.
I am not too conversant with this area and I don't know how to proceed.
Help!
Also, have you a working ODBCExpress version? (OE 5.06 for me). I starts but also locks up.
I read some more on the Asta newsgroup and the recommendation I found is to not use the AstaClientSocket in a thread. It must not be threadsafe to do so, and we are finding that it was not intended to be used in a threaded environment by design. Asta uses a non-blocking Windows socket architecture. In contrast, our report server uses a blocking threaded architecture. I still get an error in the Asta unit since I don't have source, but you could try to place the client socket in a datamodule of the main thread and since the Asta architecture uses windows sockets, you might be able to get away with this and let the background threads use the main thread client socket to access the Asta server. You may want to try using a blocking mode on the client socket for this test. What I did was use a non-databased Asta EU report that printed a label in a background thread (Report.Autostop = True) in this configuration, because the AstaClientSocket is no longer on my form, but in a data module. I get the previously mentioned 'Classes.Synchronize' error when I try to use dataviews. But I think this may just work for you with the source change for 'Classes.Synchronize.'
If no joy, an if you want to go further with this, it would really be necessary to create a simple non-RB app using Asta access components (TAstaClientDatasets) which are created on a form in a background thread which perform a table dump to a text file or something simple with the data. Then find out if this does or does not work. Then ask Steve Garland at Asta for his recommendations to get the simple app working.
It didn't for me Jim. Can you send me a link (or email me) to the ODBCExpress Dade you used? (RB7.02 D6). Was there anything in particular you needed to set in the data module?
Do you have an end user demo with ODBC Express that does background printing you can provide a link to so I can fix my project?
Comments
as easy as possible- ie. require the report to have an owner form or
datamodule and then nonot have and registration calls for report forms,
templates or archives for volumes like you do for the Server Edition.
Using the main report explorer demo project, open up the form and add a
TSession object and set Autosession name to true. Then in the OnLoadEnd
event of the report template set Report.BackgroundPrintSettings.Enabled to
true, followed by the Report.BackgroundPrintSettings.Active property. Then
run the app and print a report:)
As far as ASTA, I'll have to try it. I don't have an ODBCExpress ASTA server
running for RB, but I can test it with my local DBISAM ASTA RB end user
server.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
I understood that for the BDE but was having trouble (I got an error
only with background print trying to open the join ds) when using
Asta.
To clarify I use the report explorer with a dictionary both with Asta
and ODBCExpress in the client. If I use ASTA then the server is
actually ODBCExpress but that is not a factor in this issue I think.
Thanks,
synchronizing. So, set the client datasets ShowQueryProgress to sqDontShow.
Then set the client socket to ConnectAction to caUseDesignAddress and
AutoLoginDlg to ltLoginNoDlg. But, even after this, I don't think that the
Asta client socket is meant to run in a background thread as I get an error
from their source (AstaSmartWait.pas) as it is trying to syncronize as it
assumes it is in the main thread, which it isn't.
So, I surfed Asta newsgroup and found a post where Steve mentions that Asta
uses sockets (not threads) and threads give you nothing in performance.
Well, RB does create a socket in the background thread as it is generically
coded to support any form you have with a report on it with any data access
components that you want to print in the background. So, I ran across this
post from Steve:
"So if your thread are using the same pipe, houston we'd like to re-direct
what you are doing.
<<This comes from the call "Classes.CheckSynchronize" around line 240 in
AstaSmartWait.pas
well you can try commenting it out as we just threw that in there for D6."
I also coded this in my end user project to toggle between blocking when I
was playing around with this, but I don't have AstaSmartWait.pas in my
version of Asta, just a dcu, so I don't know if this would help:
uses
ppUtils;
{---------------------------------------------------------------------------
---}
{ TmyReportObjects.FormCreate }
procedure TmyEndUserSolution.FormCreate(Sender: TObject);
begin
ppReport1.Template.OnLoadEnd := LoadEndEvent;
ASTAClientSocket1.Active := False;
if ppInMainThread then
AstaClientSocket1.ClientType := ctNonBlocking
else
AstaClientSocket1.ClientType := ctBlocking;
ASTAClientSocket1.OpenTheSocket;
end; {procedure, FormCreate}
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
(D6 with Asta 2.6.)
I commented out the "Classes.CheckSynchronize" and it then does
connect (although the comment references D6 which is what I am using).
I am printing to a file (pdf with waler) and it starts and returns to
the designer but shortly it locks up and the file stops being updated.
I have tried blocking/nonblocking in the thread with no luck.
I am not too conversant with this area and I don't know how to
proceed.
Help!
Also, have you a working ODBCExpress version? (OE 5.06 for me). I
starts but also locks up.
Thanks,
not use the AstaClientSocket in a thread. It must not be threadsafe to do
so, and we are finding that it was not intended to be used in a threaded
environment by design. Asta uses a non-blocking Windows socket architecture.
In contrast, our report server uses a blocking threaded architecture. I
still get an error in the Asta unit since I don't have source, but you could
try to place the client socket in a datamodule of the main thread and since
the Asta architecture uses windows sockets, you might be able to get away
with this and let the background threads use the main thread client socket
to access the Asta server. You may want to try using a blocking mode on the
client socket for this test. What I did was use a non-databased Asta EU
report that printed a label in a background thread (Report.Autostop = True)
in this configuration, because the AstaClientSocket is no longer on my form,
but in a data module. I get the previously mentioned 'Classes.Synchronize'
error when I try to use dataviews. But I think this may just work for you
with the source change for 'Classes.Synchronize.'
If no joy, an if you want to go further with this, it would really be
necessary to create a simple non-RB app using Asta access components
(TAstaClientDatasets) which are created on a form in a background thread
which perform a table dump to a text file or something simple with the data.
Then find out if this does or does not work. Then ask Steve Garland at Asta
for his recommendations to get the simple app working.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
for background printing or RBServer.
Have you been able to get ODBCExpress to work?
Thanks,
patience.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
background thread..
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
ODBCExpress Dade you used? (RB7.02 D6). Was there anything in
particular you needed to set in the data module?
Do you have an end user demo with ODBC Express that does background
printing you can provide a link to so I can fix my project?
Many Thanks,