Le 15 juil. 10 à 22:09, Mark Wieder a écrit :
Andre-
Thursday, July 15, 2010, 12:52:41 PM, you wrote:
In these handlers, I distinguish the differents buttons using
if the short name of the target is "such button" then
or case the short name of the target is "such button"
(followed by the routine for this specific button)
If you have to do all that, why are you using a behavior button?
Behaviors are typically used for functionality in common with several
objects - here it seems you're doing just the opposite.
--
-Mark Wieder
[email protected]
Bonjour Mark,
Thank you for your attention.
My app. has a main stack and a dozen of substacks. Among them, is a
"stack model" which can be clone in order to create "independant"
stacks (quite a lot of) that are medical files (one file for each
patient). These independant stacks have a couple of substacks.
I made this app. first for my own physician who participated a lot to
the design and who uses it for 4 years now. He has nearly 500 patients
(so 500 independant stacks.
Up to now, the main part of the program was in the model stack so that:
1 - the program was repeated in each stacks
2 - each time I had to do the slightest modification, I had to built a
special program to convey the changes in each independant stack.
I am making a new version of this app. for others physicians friends
of mine. In order to minimize these drawbacks, I moved the content of
the scripts from the stack model to behavior buttons located on a card
2 of the main stack.
Now, there is (nearly) no code any more in the stack model hence in
any independant stack.
When I make a modification in the scripts, it is immediately available
for all the independant stacks.
Insofar as it is possible, I use behaviors typically: each time
several objects need strickly the same script.
As soon as the script of an object is rather long, this object has its
specific behavior button.
But I have also buttons or field whose scripts are similar but not
completely identical (for example they share a part of code but they
differ for another part. In such cases, I made one behavior button
only which include the part shared by the buttons involved and other
parts specific to each buttons (whence the "case the short name of the
target is "such button", "such field" etc.
Then I have a set of behavior buttons on cd 2 of my main stack: one
for the script of stack model, one for the card 1 of stack model and
generally one for groups of objects in the stack model. Generally the
groups of objects concern a great functionnaliy (from the medical
point of view.
For example I have a behavior button for the objects which are related
to the prescriptions (there are different sorts of prescriptions)
another for the buttons (on different prescription' documents) which
are used to archive the content of the prescription in special fields
etc.
So, I did not foreseen clearly that, but I am discovering that in this
way, spatially organizing the set of behavior button on card 2 of the
main stack, I am getting there a quite nice representation of the
functionnal structure of the app.
Well, I could elaborate more, but I think I begin to be too long ;-)
Sorry for that ;-)
Best regards from Grenoble
André
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
