by Sorry to broadcast this so widely, but there is a problem I cannot solve
and I need all the help I can, wherever I find it.
Our company has produced a 16-bit Windows application for a client.
This program communicates using 16-bit OLE and callback functions with
another 16-bit application running out-of-proc. The second program is
responsible for communications with an external device via the serial
port as well as other forms of connection, but for the purposes of this
question, let us assume the comms are serial.
As the user scrolls in our program, different data must be exchanged
with the external device so that what is showing on screen can be
monitored. It developed that the processing done by the second
application was intensive enough that overloads would occur that crashed
the program while scrolling so we reprogrammed it so that no
communication with the second application and the external device takes
place until the user has stopped scrolling (determined by trapping
WM_KEYUP and WM_VSCROLL). This worked well, until we noticed that users
could cause the same problem by rapid-fire pressing of the navigation
keys (as opposed to leaning on them). So we introduced another wrinkle
- a one second wait after scrolling stopped (using WM_TIMER). Only
after this one-second delay would communications with the other program
and external device be reinitiated.
This ugly kludge solved our problems, or so it seemed. Then we got
reports of occasional crashes when the program was run under Win95 and
less frequently, NT 4.0. Under Windows 3.1, everything continued to
work. Without a reasonable means of debugging this application under
Win95 (neither Codeview, the VC 1.5 IDE debuggeer could handle it and
our program was too big to have its symobl table loaded under Softice
for Win95) we are left to try solutions on whims. Eventually, it
developed that a bug fix in the second program had made our kludge with
WM_TIMER unnecessary and it was removed, solving the immediate problem.
But our client and our client's client want to understand what happened
and I don't know enough about Windows internals to tell them anything
useful. So I am asking the resources on UseNet.
The basic scenario, I believe, is this:
Our program handles a WM_TIMER message (through the message loop, not a
TIMERPROC)
and within that handler launches a call to the second process that will
result in callbacks.
This works under Windows 3.1 but not under Windows95. So the question
is, is there a basic difference in the handling of WM_TIMER messages by
the kernels of these two operating systems that would cause this
difference in behavior.
Thanks in advance for any light you can shed.
--
Steve Cohen
RDI Software Technologies
remove the ** spam remover from in front of my email address to reply.