Hi everyone,

While working and developping more and more with progress, something came to me.
When I have a huge request on Win's starting the window go on a no responding by windows. So is it possible to run the windows on a thread and all the querry work/calcul/process on another thread ?

Gooday to everyone




Active Member
Yes. Provide some more information and I'll elaborate. How is your application structured. Do you use appservers etc?


But you could make asynchronous calls to app servers.
Hi. For now I don't use app servers and I'm with openedge 10, and my soft don't use it.

What I want to do is to run the main frame with a PID and run the research on another PID, like this the app continue to run and the user can intercat with the app without going on no responding.


Well then, like I originally said, "no".

A 4gl session is aggressively single-threaded. To do thread-like processing you need to spread the task over multiple sessions (processes). One way to do that is with app servers. You have ruled that out so your options are limited. A remaining option is to start a batch process. This is less attractive than an app server because you will need to build some method for communication between the two "threads" (sessions). One relatively common way to approach that is to use some agreed upon protocol that uses database records to pass data between the processes.
So if I call a procedure file from my Window application it's in some way like multi processing ?
I will do some research on app server for my own knowledge.

Thank you for your time.



Running a procedure is part of the same thread in the session (aka "process"). When you start prowin.exe (or prowin32.exe or _progress.exe) you are starting a "sesssion" of the 4gl runtime (sometimes called the "AVM") that runs procedures. One at a time. There is exactly one thread of execution per session.

To have mutliple "threads" you must start multiple sessions. You might do that by using OS-COMMAND to shell out and start a 2nd session that runs its own "thread" and it's own procedures. But since these so-called "threads" are in distinct processes they cannot easily share data with each other (except insofar as a shared db connection happens to be a fairly "easy" way to share data).
Ok I understand all now. Thank you for your time.

best Regrads