Hi Randy,
Randy Portnoff ha scritto:
> The problem is when the delay is outside the control of the PRG code
(eg. a SQL query) where control is transferred to some other non-PRG
process and the PRG process must wait until it completes - In this case,
anything in the PRG code cannot help as is n
Hi Francesco,
The problem is when the delay is outside the control of the PRG code
(eg. a SQL query) where control is transferred to some other non-PRG
process and the PRG process must wait until it completes - In this
case, anything in the PRG code cannot help as is not running.
As I mentio
Hi Pripal and others,
sorry to jump in and if I miss something, but, reading fastly I have
understood that you have problem with long loops or intensive jobs.
In Windows I have solved it using code I have written and attached here.
Use it inside heavy loop as shown in example on top of file.
P
Hi Przemek,
For systems which supports MT we can intorduce inspector
thread...
BTW, there is a way to start a second thread in a single-threaded app
also - I am not sure how this is done but Mediator does do it in my ST app.
Randy.
___
Harbour m
Hi,
One way, specific to GTWVT, is to implement a timer
with unique id whose sole function is to refresh the window.
WM_TIMER event will not be delivered until GetMessage/DispatchMessage
loop will be reached. So, it does not solves problem at all.
Or maybe something completely different,
Hello Przemek
<<<
It's problem with GUI GTs: GTWVT and GTXWC. In the most
of GUI system application has to redraw its screen contents.
Probaly in each OS some hacks exists which alows to move
this job to OS. F.e. on some X-Window systems it's possible
to set bitamp as window background and it wil
On Wed, 11 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> While Harbour is doing the processing, the GTWVT
> window doesn't get refreshed, so the content
> is pure blank if minimizing and restoring the
> window. It also doesn't react to any system inputs.
> Maybe other GTs are affected too.
It's p
Threads can be a solution if all Windows platforms
(including all WinCE platforms) support it, but still
only for Windows.
We should also think about GTXWC, and maybe even
future GTs, so I think we need to look for a solution
which works without threads, and works above al GTs.
We happen to have
Hi Pritpal,
I don't think a timer (on the current thread)
will work. In many cases, the process consumes
all the resources of the current thread so a
timer event would not fire until the process was
complete. Therefore, I think to accomplish this,
a second thread would need to be started tha
Hello Viktor
Szakáts Viktor wrote:
>
> While Harbour is doing the processing, the GTWVT
> window doesn't get refreshed, so the content
> is pure blank if minimizing and restoring the
> window. It also doesn't react to any system inputs.
>
You just catched my thoughts, just.
One way, specific
Hi all,
There is a problem when an application is calling
a process which takes a long time, and doesn't
involve screen activity or user input processing.
(aka the code does't return to the HVM loop for a
longer time). Like a dbSetFilter() or dbPack() call
on a large table, or indexing without a
11 matches
Mail list logo
