gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] PropertySupport


From: Ian Haywood
Subject: Re: [Gnumed-devel] PropertySupport
Date: Sun, 25 May 2003 16:15:52 +1000

On Sun, 25 May 2003 13:08:08 +1000
sjtan <address@hidden> wrote:

> 
> 
> I've made a PropertySupport class like java.beans.PropertySupport.
> 
> There is a PropertySupported class in the file, which can be used
> to notify assignments to a class instances self.
>  
> 
> If the gmEditArea was reverted to it's old simple, 
> self.txt_blah = wxTextCtrl 
> self.btn_OK = wxButton
> 
> then those component creations can be detected, but only if 
> assigned to the self that is a PropertySupported class.

To be honest, I'm  still having a lot of trouble understanding this.
(I've never used Delphi or any of those things, the last time a
wrote a non-UNIX program it was still called Turbo Pascal ;-)

Apparantly, you are trying to parse the existing code to construct template 
files
for event handlers on the various widgets. Is this right?

Could you also, for those ignorant, explain what java.beans.PropetrySupported 
does? 

Another problem is most (actually, virtually all) of gnumed UI code is 
contained 
as plugins. Plugins are meant to be self-contained items of code, ideally one 
file, 
to do a specific job. Users can load and unload modules at anytime. A separate 
file  
to hold handlers complicates things, as it has to be loaded/unloaded in unison 
with
its 'original' plugin file (but certainly doable).

In addition, the current plugin system is poorly designed, as has been 
commented on before, and 
will be reworked in the (hopefully) near future. This would be a good time to 
make sure Syan's
work is intregrated with the overall plan, so it doesn't get broken again.

Proposal:

All our "hand-rolled" screen widgets, such as gmEditArea, inherit from 
gmWidget, so that they all
update their values into the common dictionary (which is a member of the plugin 
object)
Other widgets will be multiple inheritors of gmWidget and the wx original, to 
provide
this functionality to all widgets we use (even if they are otherwise ordinary 
wx widgets)

[can this end the need to scan files and add handlers in a separate file? Each 
widget could handle all of its
own events. Or am I missing something?]

Plugins then only need load () and save () methods to move the dictionary 
values to and from the 
backend database as Syan said.

load () would be called on "patient_selected" (perhaps as a "lazy" function -- 
only when the plugin
is shown onscreen)

save () is more complex, perhaps the inherited behaviour should be a few 
seconds after the last widget is updated 
(or prior
to another load () if it comes first), For the scripts widget at least, a 
specific button/function key
is needed also (in order to save and clear the fields for the next 
prescription)  

Ian

   

Attachment: pgpPhTE5jcgIn.pgp
Description: PGP signature


reply via email to

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