Hi IVAN,

 you wrote at 21.12.98  14:44 to HERBERT ROSENAU:
 
 IT>   But I don't understand why wouldn't this approach be desirable
 IT> for   long time consuming tasks? Please explain.

A message from system message queue is SENT, so this queue is blocked until
the message returns. If you POST a WM_USER to reduce the time the system
message is running you'll free the system message queue and messages can
still send through other windows.

Sending a message is always like a call to a subroutine. The caller can
only continue until the subroutine returns. Posting is like a push into a
stack or list. A pop will be done if time for that.

So if you have a truly long work to do you should post WM_USER to do a
little step then post another WM_USER and so on - or better create a
separate thread (it my be a PM thread too with an object window) an give
them signals (PM messages, pipes, queues, semaphores.....) to initiate the
long work.

 IT>   What bothers me now is this:

 IT>   Let's say I have a complex graphics application, and it takes a
 IT> very   long time to repaint the window. So what should I do when
 IT> I get a   repaint message?

 IT> 1) Do all the redrawing in the WndProc, leaving the PM frozen for
 IT> the duration of the drawing (very ugly)

No.

 IT> 2) Delegate the drawing task to another thread and return from the
 IT> WndProc immediately.

No.

for graphics:

Do the needed drawing asyncrously in a separate thread into a separate
presentation space. Flag the presentaitin space as ready to draw if the
drawing action is done.

Inside the WM_DRAW you have only to copy the ready presentation space into
the presentation space of the window. (GpiBitBlt())

for text:

In case of a Control (listbox, container.....) you'll use sometimes a long
time to collect the data to display. In that case you have to do the steps:

in init:
1. create the window hidden
2. start a separate thread to collect the data and send or post each Item/record
   into it
3. show the window if all items filled

in redraw (change a already visible window):
1. WinWindowUpdate(hwnd, FALSE) blocks the redraw on screen
2. initiate the thread to collect the data and fill in the control
   yor window will be informed for each item that is filled in
   In case of an ownerdraw listbox you can paint the item as you will
   without affecting the screen until all drawing is done
3. WinWindowUpdate(hwnd, TRUE) lets the real draw on screen

In both cases the time to draw on the screen is minimised, no flicker
beaves, the system load is minimal. Without Step 1/3 the system load is
maximal, the window flickers, .....

 IT>  Naturaly, the second alternative is more desirable, since the PM
 IT> will  continue to run and process messages. But what to do with
 IT> other  messages that may arive during this redrawing period (user
 IT> clicks on  the window etc.)? Is it safe to just ignore them and
 IT> start receiving  messages again only after the drawing ended?

No. If you have an action with a high frequence on screen updates lock the
window update. In case it is impossible to do the work really asyncrone you
should handle the pointer inside your window: If the pointer crosses the
boundary inside change the symbol to the 'egg hour' if it crosses outside
change back to normal. So it will no user action occure until you're finish
your work. Then you stop the pointer handling and the user can act
normally.

 IT>   What if another window comes to the foreground and covers your
 IT> window   while your'e still drawing? How would you go about
 IT> coding around this   and still not hog the system message queue?

Thos will start an other WM_PAINT if you do not handle the draw actions carefully.


Tschau/Bye

Herbert


--- Sqed/32 1.14/development  23: