gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] [Gnumed-bugs] <bug>: everything is working fine, exce


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] [Gnumed-bugs] <bug>: everything is working fine, except of doubl
Date: Sun, 10 Feb 2013 16:18:17 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

> user comment  : everything is working fine, except of doubled inbox list 
> entries (what actually happend before too)
> 
> client version: 1.2.8

Since I removed all code to error out early we are back to
the initial exception ...

> 2013-02-09 16:50:08  DEBUG     gm.gui 
> (/usr/share/gnumed/Gnumed/wxpython/gmExceptionHandlingWidgets.py::handle_uncaught_exception_wx()
>  #186): unhandled exception caught:
> Traceback (most recent call last):
>   File "/usr/share/gnumed/Gnumed/wxpython/gmProviderInboxWidgets.py", line 
> 947, in _lst_item_selected
>     msg = self._LCTRL_provider_inbox.get_selected_item_data(only_one = True)
>   File "/usr/share/gnumed/Gnumed/wxpython/gmListWidgets.py", line 1090, in 
> get_selected_item_data
>     return self.__data[idx]
> IndexError: list index out of range


... plus the added logging. However, since this log was
created w/o debugging we don't actually get to see more
logging ;-)   Please do provide a log with debugging
enabled. You know that it is time to send a log as soon as
you see double entries in the inbox :-)  No need to wait for
the exception. The logging will already have happened.

Let's see what we've learned about the problem:

Sometimes, when the provider inbox list is updated, the
wxPython code will not properly delete items despite being
told so (list.GetItemCount() not 0 after calling
list.DeleteAllItems()). We've proven (I think) that this
does, suprisingly, NOT relate to separate threads
interfering with each other. Thusly, double the list items
end up in the inbox (and they are NOT coming from the
database as phantom reads or some such). However, only one
set of list *data* entries are attached. That way, only the
first set of list *items* have corresponding data resulting
in an exception when an item in the second (lower) set of
items is double-clicked and GNUmed tries to fetch its
associated data (which doesn't exist).

So far, this has only be observed with "not very few" (> 50)
list items and also only when the provider inbox was told to
update its list because the content changed in the database
(say, a document was added or reviewed) AND the provider
inbox was raised very shortly after that event.

        Here the question would pop up whether it is possible
        to raise the exception by double-clicking a list item
        in the second (lower) set of items or whether it will
        also except on double-clicking the same (duplicate)
        item in the first (upper) set of identical items.

        Can we test that ?  (first double-click one
        item in the upper "half", if that does NOT raise
        the exception double-click the equivalent item
        in the lower "half" of the list)

Since I have contacted the wxPython list to no avail and
since things seem to be pinpointable to a malfunctioning
list.DeleteAllItems() I propose the following plan for the
time being:

When GNUmed detects non-0 items after deleting all items it
will loop attempting to, again, delete all items until it
either deleted all of them or else it looped 3 times.

At that point it should probably just leave things as
they are and hope for the best.

Later on, in case GNUmed tries to access the missing data,
it will

- compare the item with its counterpart in the "upper half"
- if they match (that is, they are duplicates):
        - ask whether to return the data of that item
- else error out (as it does now)

Thoughts on that (this is dangerously close to
second-guessing user intent) ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]