[Top][All Lists]
[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
pgpPhTE5jcgIn.pgp
Description: PGP signature
Re: [Gnumed-devel] PropertySupport, Karsten Hilbert, 2003/05/26