Yuri Dario wrote:
Hi Philipp,
There were cases of such dialogs in Windows, too, when the paint
handling changed slightly. That is why in the windows part there is now
the SALTIMERPROC_RECURSIVE, which tells that some timers can be executed
recursively. Have you copied that part, too ?
yes, I added also that code. Maybe this doesn't work?
in my case, the two calls to SalTimerProc do not have the
SALTIMERPROC_RECURSIVE flag.
I need to verify this, because if I don't send the
SALTIMERPROC_RECURSIVE call, the bRecursive flag is always 0 and OOo
does not process the callback.
I assume that win32 set this flag to allow executing the callback also
in recursive mode, or not?
The SALTIMERPROC_RECURSIVE message was invented to let the paint timers
come through occasionally, because painting as well as configure events
(moving and/or sizing a window) is handled via a timer to collect
subsequent events of the respective type. This led to no painting being
done as long as you moved a dialog, which was reported as a bug.
but if bRecursive is always false, then either the event handled always
has the ID SALTIMERPROC_RECURSIVE or pSalData->mbInTimerProc is always
false. The latter would mean that you don't set it in the handler, while
the first would perhaps mean that the third argument of the timer proc
has perhaps a slightly different meaning on OS/2 ? I'm of course only
speculating since i only can see the win32 in
vcl/win/source/app/saltimer.cxx.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
