mouseDown message sent but not triggering the handler in a behavior

Andre.Bisseret Andre.Bisseret at inria.fr
Fri Jul 16 02:37:00 CDT 2010


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
> mwieder at ahsoftware.net

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é




More information about the use-livecode mailing list