Well, it is clearly not limited to pediatrics and not necessarily
limited to clinical applications, although that is my focus. Yes,
it is definitely geared toward forms-based applications, especially
data-centric (but not data-intensive) apps.
Which is what most programmers write programs for I guess...
I do imagine that that it's important not to be too narrow
though. Even if most is done with labels and text entry fields,
there will certainly be times when graphs and other ways of
visualizing or entering data will be beneficial.
Yes, I would like to join forces at some point. Unfortunately, the
two architectures are enough different that I don't see a clear way
to do so in the near future, and my immediate priority is to get
some custom applications written for our NICU. The main reason I
decided to create Mindwrapper instead of using PythonCard is the
absolute need for data modeling. The second reason is the relative
desire for relative positioning.
I can understand that. But I imagine there are parts of PythonCard
that you could use. Honestly, I haven't looked very closely at
either PythonCard or Mindwrapper, but I from that little tutorial
I got a feeling of a focus and purpose, while PythonCard seems to
have become something entirely different than it was meant to be...
(Then one can also discuss whether that is good or bad... 
We need to talk. My interest in Python/wxPython grew out of an
Excel/VBA program for neonatal hyperalimentation that I wrote a
number of years ago. That application has worked well enough, but
trying extend it (or even make updates) is a nightmare. Mindwrapper
is intended to support, even promote evolutionary/incremental
design and development.
Funny!
The first thing I said when I was asked to help with this
was that this would be a problem. The paediatrician who
developed the Excel app needed some help with more advanced
stuff, like VBA. I immediately said that the worst problem
was that he was mixing code and data, and that every upgrade
would be difficult. We are now moving all data to an external
SQL database, and that removes the worst problem. There are
a lot of other problems with Excel apps though. I know, I failed
to create that great Excel app already a decade ago!
Except
for what you said, I also read this in a book I just bought.
(Writing Excel Macros with VBA):
"The code in this book has been carefully tested by at least three
individuals ... I have tested the code on more than one machine ...
Unfortunately, all three of us have run into some deviations from expected
behavior (that is, the code doesn't seem to work as advertised, or at all)
as well as some inconsistencies in code behavior (that is, the code works
differently on different systems or at different times)."
Why am I not surprised?
My client used to write BASIC as a kid, and I think he might
be persuaded to try Python in time. We agreed that it was
reasonable to see the Excel version as a prototype. AFAIK,
he has a very limited budget for this though, and no prior
Python experience.
This application lets the nurses enter weight, breat milk analysis
etc and the amounts of all the nutrition sources prescribed and
given to the baby. It will then calculate if the baby got too
much or too little of fluid, energy, fat, protein, minerals etc.
···
At 07:16 2003-03-27 -0800, you wrote:
--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se