Sudo Behaviors, wise or not?

[AndyP]

Behaviors are great but, if I have a project with lots of controls I end up with lots of separate behavior scripts and this can get a bit messy, so instead of behaviors I've started using script only stacks where I check for the target and the owner of the target. This allows multiple control scripts to be added to one script only stack and allows easy script separation, having script only stacks for various types of controls.

So for example, create a stack only stack named "Button Behaviors" with the following code

Code: Select all

on mouseUp
   getTarget
end mouseUp


command getTarget
   
   switch the owner of the target
      
      case "card id 1002"
         
         switch the target
            case "button " &quote&"1"&quote
               answer "HI button 1 of card 1002"
               break
            case "button " &quote&"2"&quote
               answer "HI button 2 of card 1002"
               break
            case "button " &quote&"3"&quote
               answer "HI button 3 of card 1002"
               break
         end switch
         
         break
         
      case "card id 1006"
         
         switch the target
            case "button " &quote&"1"&quote
               answer "HI button 1 of card 1006"
               break
            case "button " &quote&"2"&quote
               answer "HI button 2 of card 1006"
               break
            case "button " &quote&"3"&quote
               answer "HI button 3 of card 1006"
               break
         end switch
         
         break
         
   end switch
   
end getTarget

Then create a normal stack with 2 cards make sure the card are named "card id 1002" and "card id 1006"
Add 3 buttons on each card named "1","2","3"
Add to the card script

Code: Select all

on openStack
   start using stack "Button Behaviors"
end openStack

Then action the openStack message.

Testing for the owner of the target allows for the same named controls to be on multiple cards, so the above example has 2 cards, 6 buttons and 1 script only stack for all of the 6 button actions.

I haven't as yet had any problems with this method and it has reduced the number of scripts in my projects considerably.

So what do you think? Can you see any pitfalls or problems I might be building for the future?

[Klaus]

Hi Andy,

So what do you think? Can you see any pitfalls or problems I might be building for the future?

oh, yes! NEVER EVER name your objects as numbers? NEVER!
Since LC is typeless, everything is a string, so
-> button "1"
is seen as
-> button 1
by Livecode, even it is NOT the first button on the card!
Use a prefix if neccessary -> button "b1" or something.

Best

Klaus

[AndyP]

Hi Klaus

Hi Andy,

So what do you think? Can you see any pitfalls or problems I might be building for the future?

oh, yes! NEVER EVER name your objects as numbers? NEVER!

Never would in the real world, but it was quick and easy just for the example , should have seen the hand slapping coming for this one!

[andresdt]

you created a code stack just to put mega behavior.

You can create one for each type of control, this way neither you nor the motor have to worry about which card has the control.

Create a code stack just to put mega behavior. You create one for each type of control and that way neither you nor the motor have to worry about which card owns the control.

Now imagine you have an application with 10 cards and 100 buttons. I think your switch structure is starting to grow a lot and become more complex .

But if we used a behavior for each type of buttons, we would have only 10 script stacks or maybe a few more. If we name those batteries in such a way that just by looking at them we know what it does. We won't have to search many lines of code to find what we want to change. Also we will not have to change it in more than one place.

what i mean instead of having a stack for all the buttons. Using the idea from your example you will have three stacks, one for each button.

Code: Select all

script "buttonTypeAnswerBeh"
on mouseUp
 answer the name of me
end mouseUp

or create a behavior stack for the cards

Code: Select all

script "CardTypeAnswerBeh"
on mouseUp
if the word 1 of the name of the target is "button" then answer the name of me &&
end mouseUp

is my thought

[Klaus]

Hi Andy,

Hi Klaus

Hi Andy,

So what do you think? Can you see any pitfalls or problems I might be building for the future?

oh, yes! NEVER EVER name your objects as numbers? NEVER!

Never would in the real world, but it was quick and easy just for the example , should have seen the hand slapping coming for this one!

OK, just wanted to be sure!

[AndyP]

what i mean instead of having a stack for all the buttons. Using the idea from your example you will have three stacks, one for each button.

Code: Select all

script "buttonTypeAnswerBeh"
on mouseUp
 answer the name of me
end mouseUp

or create a behavior stack for the cards

Code: Select all

script "CardTypeAnswerBeh"
on mouseUp
if the word 1 of the name of the target is "button" then answer the name of me &&
end mouseUp

is my thought

Thanks for the feedback, but It's the multiple stacks I want to try and get away from but still have the functionality of sharing text file format on GitHub.
The example I gave was maybe too simplistic. Each of the buttons in a real project would have a call to it's own routine and functions doing different tasks.

e.g.

Code: Select all

 switch the target
            case "button " &quote&"butGetCountDownClock"&quote
               getCountDownClock
               break
            case "button " &quote&"butLoadJsonFile&quote
		loadNewJsonFile
                break
            case "button " &quote&"butCompareLaunchStats"&quote
               compareLaunchStats
               break
         end switch

This has the added advantage of allowing me to use local vars to communicate between the different button routines, whereas in a version with multiple stacks for the buttons, I would have to use global vars or custom properties to communicate between the stacks.

By the way, your PolyGrid project looks great, keeping an eye on this one.

[Klaus]

Hi Andy,

save some typing by just nesting two SWTICH clauses:

Code: Select all

...
  put the target into tTarget
   put the short name of the target into tShortTarget
   
   switch word 1 of tTarget
     ## First check all buttons:
      case "button"
      
        ## Now check the name of the buttons
         switch tShortTarget
            case "butGetCountDownClock"
               getCountDownClock
               break
            case "butLoadJsonFile"
               loadNewJsonFile
               break
            case "butCompareLaunchStats"
               compareLaunchStats
               break
         end switch
         break
         ## Now fields etc...
      case "field"
         ...

You get the picture.


Best

Klaus

[andresdt]

In my humble opinion, since I am a self taught programmer. Having that bunch of files, one for each behavior. It offers many advantages, which I think may outweigh any disadvantages it may have.
I learned to program with LiveCode. So when jumping to other languages ​​it was very difficult for me to understand why I had to have a file for the view, another for the controllers and another for the models (MVC). Even work with. Net Core and we developed an API with the repository pattern and sometimes it had a handler that did exactly the same as another. Still, they told me that I had to create a file for each one. Which seemed silly to me, if I already had a manipulator who did exactly the same thing. Everything changed when in one of the two, they asked me to include a new data. The pile of files no longer looks silly. Well, that is one of the principles of OOP called Encapsulation.

See the following post: https://www.freecodecamp.org/news/objec ... b035f7260/

I know you must already know all this , it's in case someone new to LC goes through this thread.
Going back to your idea, when you use a behavior for each button or object. This is called and runs quickly. While in the way you propose it has to go through a series of checks to see if it meets all of them and then execute the corresponding code

Besides the laziness of writing all those cases. jjj

[AndyP]

Also a self taught programmer (it shows!) and I have picked up lots of bad or non-standard habits I'm sure. but, I think that is one of the unsung strengths of LiveCode, it's not overly strict and fairly forgiving, much like my self, so my boys would tell me so many destinations can be reached via many routes. Previously to Livecode, I mainly programmed in Delphi - Pascal which was stricter but still used an English language like syntax.

When i discovered LiveCode, RunRev as it was then V3.2, it was like hey this works like I think, it's a bit messy but but I can get a lot done very quickly.

I've nether worked as a programmer as part of a team and that's really important driver as to ones programming style, I'm the only one who has to re read my code at a later date and understand the code flow. This leads to different routes on the code journey, a journey where if I take a wrong turn I can always retrace my tracks and decide to turn in a different direction, I'm not bound by the A to B routes and road rules set by the team environment.

Is this good, bad? In the end I don't think it matters as long as we enjoy the journey and take in the scenery on the way

Thanks for the link How to explain object-oriented programming concepts to a 6-year-old https://www.freecodecamp.org/news/objec ... b035f7260/ I'm not sure but I think that the target audience of a 6 year old may be a little on the low side

[andresdt]

You are absolutely right. The most important thing is to enjoy the trip.
To go from Portugal to the Philippines, you can use the Strait of Hormuz or skirt the African coast. It's all a matter of taste jjj