[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mouse handler table inconsistency.
[SLUG added in case anyone else out there has been experiencing the
following symptom and has any insight. We're currently running 8.0 Beta
but I have no reason to believe that this problem is specific to that
version of Genera.]
Date: Wed, 4 Apr 90 17:53 PDT
From: Mark Freeman <MFreeman@VERMITHRAX.SCH.Symbolics.COM>
Date: Mon, 2 Apr 90 14:58 PDT
From: Robert D. Pfeiffer <RDP@ALAN.kahuna.decnet.lasc-research.lockheed.com>
"Once in a while", our application generates the following notification.
I have no idea why. As it says, the problem is automatically corrected
so it's no big deal. Nevertheless, it bothers me that there's something
wrong which I don't understand. Can anyone provide some insight as to
what this might mean and how to fix it properly?
3/21 10:48:46 An inconsistency was found in the mouse handler tables
OPTIM::SELECT-THIS-OBJECT is missing from the table
at context = CP:COMMAND
and displayed = OPTIM::PSEUDO-TASK
Entry = (OPTIM::SELECT-THIS-OBJECT
-PREDICATE-INTERNAL 0 TYPE...
Entry-list = NIL.
It will be automatically corrected.
I think the problem is that Entry-list is NIL. The Entry-list
is obtained from the table
dw::*presentation-type-mouse-handler-table*, so for some reason,
dw::verify-handler-entry-in-table can't find the handler table
element for handler OPTIM::SELECT-THIS-OBJECT. As the message
says, it will go ahead and create the entry-list for you. I'm
not sure why that could be missing, maybe the table didn't get
copied correctly while it was being grown, or mutated?
I'm sure I don't know.
Does it
always happen on one of your own defined handlers?
Yes, so far as I know.
P.S. Setting *background-notifies-for-missing-handlers* to NIL
should make the notifications go away. (but
dw::verify-handler-entry-in-table will still fix things for you)
Thanks, I'll use this as a last resort if I can't fix my application
properly before it goes into Beta Test.