Need a way to run a procedure without holding up my current procedure

[walkeryan]

I need to find a way that I can run a procedure(.p) from a window but without pausing the user input on the window. I know there is some way to do it with the ASYNCHORONIS opton but I think you need and appserver and we dont have one. Right now were just putting them in batch files and firing them off but if an error happens in the batch file we have no way of detecting it and it is tedious to write a batch for ever procedure we need to run. Any thoughts/suggestions? Thanks in advance

 

[RKR]

I need to find a way that I can run a procedure(.p) from a window but without pausing the user input on the window. I know there is some way to do it with the ASYNCHORONIS opton but I think you need and appserver and we dont have one. Right now were just putting them in batch files and firing them off but if an error happens in the batch file we have no way of detecting it and it is tedious to write a batch for ever procedure we need to run. Any thoughts/suggestions? Thanks in advance

Without an appserver there are still some possibilities that might work. If the program you are running is looping, for instance a for each you can use PROCESS EVENTS in the loop. Every time progress executes this statement it will handle queue'd events. like keystrokes. If the loop is fast it will not be a problem and it will look like as if 2 programs are running at the same time. However when the window is closed and this procedure is running it might cause some problems.

Also keep in mind that the longer the time between each Process events the slower the window will seem to work.

Another option is start this procedure by opening a new prowin32.exe session without the -b parameter. Then errors from this procedure will appear on your screen. Only if you need the result from this procedure in your window then you will have to find a way to send the result between the 2 sessions. For instance put the result in the database, or have the sessions talk to each other using sockets etc.

 

[walkeryan]

"Another option is start this procedure by opening a new prowin32.exe session without the -b parameter. Then errors from this procedure will appear on your screen. "

I'm not to familiar with this, how would I go about doing it?

 

[lord_icon]

Simply look at running the procedure PERSISTENT.
/* code block */
DO .....
RUN dude.p PERSISTENT hdlProc /* assign a handle to the process */
DO ....

 

[walkeryan]

Simply look at running the procedure PERSISTENT.
/* code block */
DO .....
RUN dude.p PERSISTENT hdlProc /* assign a handle to the process */
DO ....

I tried this but it still makes my window wait until the procedure is completed. The proc take about 5 minutes to complete . Do I need to assign the handle after PERSISTENT to anything?

 

[FrancoisL]

I tried this but it still makes my window wait until the procedure is completed. The proc take about 5 minutes to complete . Do I need to assign the handle after PERSISTENT to anything?

Running a procedure Persistent does not make it Multi-Threading . Your program will still wait for your code to finish.

 

[RKR]

Without an appserver there are still some possibilities that might work. If the program you are running is looping, for instance a for each you can use PROCESS EVENTS in the loop. Every time progress executes this statement it will handle queue'd events. like keystrokes. If the loop is fast it will not be a problem and it will look like as if 2 programs are running at the same time. However when the window is closed and this procedure is running it might cause some problems.

Also keep in mind that the longer the time between each Process events the slower the window will seem to work.

Another option is start this procedure by opening a new prowin32.exe session without the -b parameter. Then errors from this procedure will appear on your screen. Only if you need the result from this procedure in your window then you will have to find a way to send the result between the 2 sessions. For instance put the result in the database, or have the sessions talk to each other using sockets etc.

os-command value("<path>\prowin32.exe -ini <inifile> -pf <pffile> -p yourprocedure.p").

Look for the exact parameters for your ini and pf in the shortcut to your progress application. It will simply start a new session of progress and by using the -p parameter you can specify what program to run.

 

[sphipp]

That will still wait for the second session to complete.

If you use os-command no-wait then the calling program will come back immediately and will continue its processing alongside the new session.

You could use the -param option to pass parameters into your program. That way, you could call the secondary program with various options.

If you wanted, you could link to an external file which contained extra parameters or set up a table that contained session parameters to be used.

But, that might be getting a bit complicated for what you need.