gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: [Fwd: Re: Attn Ian: re LIstbook in gnuMed 'terry'


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: [Fwd: Re: Attn Ian: re LIstbook in gnuMed 'terry']
Date: Thu, 17 Mar 2005 14:49:24 +0100
User-agent: Mutt/1.3.22.1i

> The dispatcher.send() shouldn't be wrapped in a try: catch block as a hacky
> sacrifice to impatient module writers,
No, wait, I do think you have a point there. I do think it is
OK to catch those exceptions, report them and try to continue.

> because release modules should not
> be throwing uncaught exceptions.
True enough.

> However, for individuals wanting to do some
> debugging/coding, there's nothing wrong with adding try: catch blocks 
> here and
> there, like print statements, for debugging,
Agree.

>  As for the paint event, it's designed to delay time-consuming updates when
> the model changes, until the time a module tab is displayed, so like the 
> previous
> thread about how to solve document scanning affecting network performance
> of a emr, it's a matter of good  resource use design. 
> There isn't enough time for 0.1 release to redesign model-view 
> interaction to using
> threads , which would be a much more complicated way of  managing  gui 
> responsiveness,
> and prone to non-deterministic bugs,
> and at least trying to manage gui responsiveness using the paint event  
> is much
> better than leaving an overly simplistic dispatcher push update which causes
> the gui to block  until  all modules are updated, whenever a dispatcher 
> notification occurs.
Good summary of the intent !

> I apologize for being a bit too open about code critiques,
Personally, I don't mind. Most of the time when you directly
questioned the quality of a piece of code (not the concept of
why it is there at all) you had found a bug. Why would we not
want to know that ?

> to make me look more amatuer about getting things to work e.g. I used sql to
> update the cfg_string between status_quo and terry ,
There's nothing amateurish about getting this done at the SQL level !

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




reply via email to

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