R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Author |
Message |
Clifford Wierni #1 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
I use the dos version of r&R report writer. I am experiment with calling the windows R&R report writer runtime rrwrun. It works fine but I have a behavior difference under windows 9x and windows 2000. The behavior difference is the same under blinker 6.0 regardless if swpruncmd is used or overlay is used. Under DOS rrun, when the run time is called via swpruncmd or overlay, the clipper program pauses until the runtime is exited and then processing continues at the next command line in the clipper program. Calling the windows runtime rrwrun, with same program and swpruncmd or overlay, under W2000 the behavior is the same. However, under win9x, it is as if the rrwrun program is called in a different thread because the clipper program does not pause. The windows runtime is loaded and is functional but the clipper program continues immediately and does not wait for the report program to be exited. Has anyone experienced this and is there a way to control this behavior.
|
Tue, 04 May 2004 07:10:01 GMT |
|
|
Ralf Meye #2 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Quote:
> Calling the windows runtime rrwrun, with same program and swpruncmd or > overlay, under W2000 the behavior is the same. However, under win9x, it > is as if the rrwrun program is called in a different thread because the > clipper program does not pause. The windows runtime is loaded and is > functional but the clipper program continues immediately and does not > wait for the report program to be exited.
Have a look at: start /? (not really clipper related.)
|
Wed, 05 May 2004 02:44:51 GMT |
|
|
Ralf #3 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Hi Clifford, rrwrun is starting its own process. I didnt find a way to ask inside clipper, whether a windowsprocess is still running or not. But rrwrun needs the rrunout.dbf to write down a statement about successfull printing or whether an error occured during printing. So I delete this database before swapping to rrwrun.exe. If this database is back in the directory, the printingprocess is stopped. Even if you put your printing to the display, the rrunout.dbf is only created by rrwrun, when the preview-window is closed. So you can ask in do while statement for the appearing of rrwrunout.dbf. For example: ____________________________________________________________________________ ________________________ cDiPi := rg_DiPi(cDiPi) //Function, where the user is asked, whether he wants the printing on the screen or to the printer erase rrunout.dbf // time to delete the database NET_DBF (3,10, network_yn, "RRWRUNIN", .F., "") // NETZ: USE.. NET_RLCK (3,10, network_yn) // NETZ: Satz-Sperrung REPLACE Ri_report WITH N_FDrive()+N_FPath()+"KUNDENUM.RRW" REPLACE Ri_master WITH N_FDrive()+N_FPath()+"KUNDUMS.DBF" REPLACE Ri_printer WITH cDiPi REPLACE Ri_wtitle WITH "ASS Kunden-Umsatzliste" for net__iii = 1 to net_maxdbf // NETZ: closing all indizes and databases select (net__iii) // NETZ: NTX schliessen. NET_DBF (3,10, network_yn, '', .F.) // NETZ: Wiederer"ffnung next // NETZ: mit NET_REOP (..) swpgetkey(.f.) ret_var = SWPRUNCMD("rrwrun rrwrunin 1 /B",0,"","") do while !file("RRUNOUT.DBF") .AND. LastKey()<>K_F10 //F10 is my breaking key OL_Yield() // TimeSlices an Windows INKEY() ENDDO SELECT 0 NET_DBF (3,10, network_yn, "RRUNOUT", .F., "") // NETZ: USE.. nReports := 0 NET_DBF (3,10, network_yn, '', .F.) // NETZ: USE (close) // At this time, we have a database without fields. Give rrwrun.exe the time to do its work. // The field ro_reports tells me, if printing was successfull or not. DO WHILE nREPORTS <> 1 .AND. LastKey()<>K_F10 NET_DBF (3,10, network_yn, "RRUNOUT", .F., "") // NETZ: USE.. nReports := RO_REPORTS IF ro_ecode="R" BREAK ENDIF NET_DBF (3,10, network_yn, '', .F.) // NETZ: USE (close) OL_Yield() inkey() ENDDO OL_WinFullScreen() // printing was ok, back to fullscreen. The Clipper-Application comes back ---------------------------------------------------------------------------- -------------------------- I know, this is not a glorius way of programming, but it works. Perhaps, someone has a better idea. Ralf
Quote: > I use the dos version of r&R report writer. I am experiment with > calling the windows R&R report writer runtime rrwrun. It works fine but > I have a behavior difference under windows 9x and windows 2000. The > behavior difference is the same under blinker 6.0 regardless if > swpruncmd is used or overlay is used. > Under DOS rrun, when the run time is called via swpruncmd or overlay, > the clipper program pauses until the runtime is exited and then > processing continues at the next command line in the clipper program. > Calling the windows runtime rrwrun, with same program and swpruncmd or > overlay, under W2000 the behavior is the same. However, under win9x, it > is as if the rrwrun program is called in a different thread because the > clipper program does not pause. The windows runtime is loaded and is > functional but the clipper program continues immediately and does not > wait for the report program to be exited. > Has anyone experienced this and is there a way to control this behavior.
|
Wed, 05 May 2004 03:53:53 GMT |
|
|
Mike Murc #4 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
This is a quite old problem that started with the first version of R&R for Windows and Win 95. I have written up the problem several times to the old and new R&R owners and even though they have released 6.5, 7.0, 7.1,8.0 and now version 9, they still have not addressed this basic problem. Each upgrade cost more than the original DOS version. I have tried "start". I have looked for rrunout.dbf. If the rrunout.dbf code works, I am surprised and will try it again. It works great on all the DOS versions of RR, it is just that awful multi-tasking ability of Windows that kills you! I still use the R&R for Windows because of the printer support and the preview is much better than the DOS version.
Quote: > I use the dos version of r&R report writer. I am experiment with > calling the windows R&R report writer runtime rrwrun. It works fine but > I have a behavior difference under windows 9x and windows 2000. The > behavior difference is the same under blinker 6.0 regardless if > swpruncmd is used or overlay is used. > Under DOS rrun, when the run time is called via swpruncmd or overlay, > the clipper program pauses until the runtime is exited and then > processing continues at the next command line in the clipper program. > Calling the windows runtime rrwrun, with same program and swpruncmd or > overlay, under W2000 the behavior is the same. However, under win9x, it > is as if the rrwrun program is called in a different thread because the > clipper program does not pause. The windows runtime is loaded and is > functional but the clipper program continues immediately and does not > wait for the report program to be exited. > Has anyone experienced this and is there a way to control this behavior.
|
Wed, 05 May 2004 05:03:37 GMT |
|
|
Ross McKenz #5 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Quote:
>Hi Clifford, >rrwrun is starting its own process. I didnt find a way to ask inside >clipper, whether a windowsprocess is still running or not.
Hello Ralf and Clifford, The issue of being able to detect active window processes via Clipper came up some time ago (maybe 4 years ago). The following text describes what I did to solve this generic problem in the context of the specific application. The technique could be applied equally well in your case. If you want the code just ask. Regards, Ross McKenzie ValuSoft Melbourne Australia /* Launch an FTP session specifically to collect the DigiKey pricelist and daily stock situation in support of the ES+S production planning system. Uses the shareware WS_FTP95 Limited Edition windows program to collect the file. This windows program can be started from a dos box with commandline parameters. It provides an on-screen progress box and "Cancel" button" which is important for this 1 MByte file download. The WS_FTP95 program has been installed in the C:\FTP directory to avoid the problem caused by the space in the long directory name of launching from the default "C:\Program Files\WS_FTP" directory. The specific contact details of ftp address, starting directory, user id, password are stored in the profile "DigiKey" which WS_FTP95 creates and stores in its WS_FTP.INI file. The alternative is an all-too-long command line string. This calling program, MakeSond.EXE, must be forced into a window before the WS_FTP95 is launched. As there is no function available to do this programatically, the operator is prompted to do so. Immediately after the WS_FTP95 program has been launched, focus is returned to the Makesond program. However, in this instance, we do not want Makesond to be returned to normal operation because of the need to UnZip the incoming file immediately following the completion. Use is made of a file called PS.EXE supplied by Dave Pearson and renamed for clarity only as WINPROGS.EXE. WINPROGS.EXE examines the Windows processing queue and writes the details to a text file which is examined until the string WS_FTP95 is NOT found which means the FTP process has been completed. */
|
Wed, 05 May 2004 07:06:19 GMT |
|
|
Clifford Wierni #6 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Thanks for the various replies. It is usual for Microsoft that they make win 9x and W2000 behave differently. I will try these but the check for the rrunout.dbf seems like a good approach. I will at the others also. Thanks again. Cliff. Quote:
> This is a quite old problem that started with the first version of R&R for > Windows and Win 95. I have written up the problem several times to the old > and new R&R owners and even though they have released 6.5, 7.0, 7.1,8.0 and > now version 9, they still have not addressed this basic problem. Each > upgrade cost more than the original DOS version. > I have tried "start". I have looked for rrunout.dbf. If the rrunout.dbf > code works, I am surprised and will try it again. It works great on all the > DOS versions of RR, it is just that awful multi-tasking ability of Windows > that kills you! > I still use the R&R for Windows because of the printer support and the > preview is much better than the DOS version.
> > I use the dos version of r&R report writer. I am experiment with > > calling the windows R&R report writer runtime rrwrun. It works fine but > > I have a behavior difference under windows 9x and windows 2000. The > > behavior difference is the same under blinker 6.0 regardless if > > swpruncmd is used or overlay is used. > > Under DOS rrun, when the run time is called via swpruncmd or overlay, > > the clipper program pauses until the runtime is exited and then > > processing continues at the next command line in the clipper program. > > Calling the windows runtime rrwrun, with same program and swpruncmd or > > overlay, under W2000 the behavior is the same. However, under win9x, it > > is as if the rrwrun program is called in a different thread because the > > clipper program does not pause. The windows runtime is loaded and is > > functional but the clipper program continues immediately and does not > > wait for the report program to be exited. > > Has anyone experienced this and is there a way to control this behavior.
|
Wed, 05 May 2004 10:33:02 GMT |
|
|
Nick Rams #7 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
On Thu, 15 Nov 2001 17:10:01 -0600, Clifford Wiernik Quote:
>I use the dos version of r&R report writer. I am experiment with >calling the windows R&R report writer runtime rrwrun. It works fine but >I have a behavior difference under windows 9x and windows 2000. The >behavior difference is the same under blinker 6.0 regardless if >swpruncmd is used or overlay is used. >Under DOS rrun, when the run time is called via swpruncmd or overlay, >the clipper program pauses until the runtime is exited and then >processing continues at the next command line in the clipper program. >Calling the windows runtime rrwrun, with same program and swpruncmd or >overlay, under W2000 the behavior is the same. However, under win9x, it >is as if the rrwrun program is called in a different thread because the >clipper program does not pause. The windows runtime is loaded and is >functional but the clipper program continues immediately and does not >wait for the report program to be exited. >Has anyone experienced this and is there a way to control this behavior.
try this: swpruncmd("Start/w rrwrun") start/w forces the caller to wait for the callee to terminate. -- Nick Ramsay WitzEnd Computer Services
|
Wed, 05 May 2004 03:52:40 GMT |
|
|
Mike Murc #8 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Ross, You are obviously correct in identifying this as a problem running all Windows programs and not just R&R. I still expected something better from R&R like the code you and Dave made to check the que. I would like to see Dave's code on checking the que. I wonder if it covers all Windows versions including varieties of NT. Mike
Quote:
> >Hi Clifford, > >rrwrun is starting its own process. I didnt find a way to ask inside > >clipper, whether a windowsprocess is still running or not. > Hello Ralf and Clifford, > The issue of being able to detect active window processes via Clipper > came up some time ago (maybe 4 years ago). The following text > describes what I did to solve this generic problem in the context of > the specific application. The technique could be applied equally well > in your case. > If you want the code just ask. > Regards, > Ross McKenzie > ValuSoft > Melbourne Australia > /* > Launch an FTP session specifically to collect the DigiKey pricelist > and daily stock situation in support of the ES+S production planning > system. > Uses the shareware WS_FTP95 Limited Edition windows program to > collect the file. This windows program can be started from a dos box > with commandline parameters. It provides an on-screen progress box > and "Cancel" button" which is important for this 1 MByte file > download. > The WS_FTP95 program has been installed in the C:\FTP directory to > avoid the problem caused by the space in the long directory name of > launching from the default "C:\Program Files\WS_FTP" directory. > The specific contact details of ftp address, starting directory, > user id, password are stored in the profile "DigiKey" which WS_FTP95 > creates and stores in its WS_FTP.INI file. The alternative is an > all-too-long command line string. > This calling program, MakeSond.EXE, must be forced into a window > before the WS_FTP95 is launched. As there is no function available to > do this programatically, the operator is prompted to do so. > Immediately after the WS_FTP95 program has been launched, focus is > returned to the Makesond program. However, in this instance, we do > not want Makesond to be returned to normal operation because of the > need to UnZip the incoming file immediately following the completion. > Use is made of a file called PS.EXE supplied by Dave Pearson and > renamed for clarity only as WINPROGS.EXE. WINPROGS.EXE examines the > Windows processing queue and writes the details to a text file which > is examined until the string WS_FTP95 is NOT found which means the > FTP process has been completed. > */
|
Wed, 05 May 2004 21:36:37 GMT |
|
|
Ross McKenz #9 / 9
|
R&R report writer rrwrun/ clipper 5.2e/w9x/w2000
Quote: >Ross, >You are obviously correct in identifying this as a problem running all >Windows programs and not just R&R. I still expected something better from >R&R like the code you and Dave made to check the que.
Hi Mike, Small correction. Dave pointed me at the source of the original utility. I cannot recall the name of the author (but he deserves a medal). I simply wrote the Clipper code around it to extract the name of the windows app that I was interested in from the queue. I just tried it again using my NT4 system and it works. I can supply the .exe of the utility....not sure if I ever had the source for it. Regards, Ross Quote: >I would like to see Dave's code on checking the que. I wonder if it covers >all Windows versions including varieties of NT. >Mike
>> >Hi Clifford, >> >rrwrun is starting its own process. I didnt find a way to ask inside >> >clipper, whether a windowsprocess is still running or not. >> Hello Ralf and Clifford, >> The issue of being able to detect active window processes via Clipper >> came up some time ago (maybe 4 years ago). The following text >> describes what I did to solve this generic problem in the context of >> the specific application. The technique could be applied equally well >> in your case. >> If you want the code just ask. >> Regards, >> Ross McKenzie >> ValuSoft >> Melbourne Australia
|
Thu, 06 May 2004 06:31:48 GMT |
|
|
|