[Gnumed-devel] wxPython strangeness

[Karsten Hilbert]

Hi all,

I have successfully gotten the backend listener threads to
sync with main() on exit of GnuMed. The allergy field in the
top panel now also dutyfully updates upon insertion of new
allergies for the selected patient into the backend.

-----------------------------
INTERJECTION:
The problem's got a solution as I found out:

 
http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?11:mss:18816:200305:hpjijmhmjjahccgkigpd

So, let's turn this into an item to be remembered: wxPython GUI
functions cannot be called from threads. So if you update the
GUI based on backend signals use wxCallAfter() ...
-----------------------------
And so the story goes:

There's one strange thing, though: When the clinical record
object sends the allergy update signal to the frontend via
gmDispatcher wxPython complains about the idle() handler being
installed twice. I checked the code but was unable to find
anything at all related to that.

Observe the following session log (>>>>> comments):
#-------------------------------------------------------------------------
»Script« wurde gestartet: Sat May  3 15:30:30 2003
address@hidden:~/Projekte/GNUmed/gnumed/gnumed/client/wxpython> gnumed.sh
Determining GnuMed base directory ...
- environment variable GNUMED_DIR not set
  (only necessary if nothing else works, though)
- standard path [/usr/share/gnumed/] not accessible
- seems like we are running from an arbitrary
  directory (like a CVS tree or on Windows)
log file is [/var/log/gnumed/gnumed.log]
Activating verbose log level for debugging.

[...snip...]

1 patient IDs fetched in 0.094 seconds
    >>>>> selected a patient
allergy update: {}
    >>>>> upon which the top panel updates itself
    >>>>> I now insert a few allergies
allergy add/del signal from backend received
    >>>>> and the clinical record receives a notification about that
# allergies changed, invalidating cache, sending frontend signal
    >>>>> it finds, that indeed the # of allergies has changed
    >>>>> for its patient
allergy update: {'signal': 'allergy_updated', 'sender': 'gmClinicalRecord'}
    >>>>> the top panel gets the notification
allergy add/del signal from backend received
    >>>>> same story, clinical record receives backend signal
# allergies changed, invalidating cache, sending frontend signal
    >>>>> tells frontend about it
allergy update: {'signal': 'allergy_updated', 'sender': 'gmClinicalRecord'}
    >>>>> frontend gets it
[Debug] 15:32:05: C++ assertion "wxTheApp->m_idleTag == 0" failed in 
/projects/wx/wxPython/_build_rpm/rpmtop/BUILD/wxPythonSrc-2.4.0.1/src/gtk/app.cpp(364):
 attempt to install idle handler twice
    >>>>> HUH ?!? Pardon me ?
allergy add/del signal from backend received
    >>>>> and same story all over again, backend -> clinical record
# allergies changed, invalidating cache, sending frontend signal
    >>>>> clinical record -> frontend
allergy update: {'signal': 'allergy_updated', 'sender': 'gmClinicalRecord'}
    >>>>> frontend -> console
[Debug] 15:32:05: C++ assertion "wxTheApp->m_idleTag == 0" failed in 
/projects/wx/wxPython/_build_rpm/rpmtop/BUILD/wxPythonSrc-2.4.0.1/src/gtk/app.cpp(364):
 attempt to install idle handler twice
    >>>>> TADA !!
Traceback (most recent call last):
  File "/home/ncq/Projekte/GNUmed/gnumed/gnumed/client/wxpython/gmGuiMain.py", 
line 365, in Callback_UpdateTime
    self.SetStatusText(st,1)
  File "/usr/lib/python2.1/site-packages/wxPython/frames.py", line 111, in 
SetStatusText
    val = apply(framesc.wxFrame_SetStatusText,(self,) + _args, _kwargs)
wxPython.wxc.wxPyAssertionError: C++ assertion "wxTheApp->m_idleTag == 0" 
failed in 
/projects/wx/wxPython/_build_rpm/rpmtop/BUILD/wxPythonSrc-2.4.0.1/src/gtk/app.cpp(364):
 attempt to install idle handler twice
    >>>>> Now, this is probably delayed fallout from the above
    >>>>> situation ...

[...snip...]

address@hidden:~/Projekte/GNUmed/gnumed/gnumed/client/wxpython> exit

»Script« beendet: Sat May  3 15:32:20 2003
#-------------------------------------------------------------------------

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346