About one year ago I made a patch to the windows timer. At the time the timer ID was using an integer greater than 16 bits and provoked a bug with Hewlett Packard printer drivers.
I suspected that the subject could resurface over, so I left some comments and an UT_ASSERT to that effect in the file UT_Win32Timer.cpp. Please use Windows timer IDs carefully ;) Gilles Saint-Denis ----- Original Message ----- From: Martin Sevior <[EMAIL PROTECTED]> To: Kenneth J.Davis <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, March 27, 2002 12:01 AM Subject: Re: please comment, possible fix for 2912, involves UT_Timers > > I believe a proper fix is to make sure the UT_Win32Timer > > returns a unique and nonchanging id. I have an idea of how to > > do this. But I'm open to suggestions, as they will probably be > > simpler and better than what I'm considering; or if you think > > I'm incorrect on this issue, let me know what you think the cause is > > or suggestions to try to better isolate the cause. Right now the > > crash occurs when attempting to delete a non NULL m_pRedrawUpdateTimer, > > which definitely has the wrong id from any Timer's in the static > > vector of timers (it appears to be pointing to already free'd > > memory, though this is based on intuition and not fact). > > > > Getting the windows UT_Timer to return a unique ID would be by far the > best solution. The Unix timer function does this by construction. > > A really quick fix that fails about once in a billion is to just call > UT_Rand() and use that for the timer ID. An alternatitive would be to > invent UT_UniqueID which has private member variable which incremented > after every request for a unique ID. Since the ID is local to each > invocation of abiword it could just start at 0. >
