
Random message pops up but within constraints
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: Random message pops up but within constraints
also see my edits above your post on the previous page 

Re: Random message pops up but within constraints
Ah, thanks for the heads up. I'm a little confused, though, with the terminology. It feels like I'm hearing two different things from you and Craig. I'm new, though, so I'm sure it's me still trying to interpret what you guys mean since I still am learning the context for everything from scratch. I'm actually going through the Beginner's Guide right now...
Re: Random message pops up but within constraints
It's not two different things, just that the subtleties are subtle, but understanding what they are will help you enormously.
In Craig's example, he put a "send" statement in the handler script on mouseUp. When you clicked the button (as well as various other messages) it generated a mouseUp message. In the button script there is an "on mouseUp" handler, so the mouseUp message is dealt with. In this case, the handler created another message "displayMessage" and sent that to the message path to seek a handler. It just so happened that you made the "on displayMessage" handler in the same script, so it didn't have far to go in the message path before it got handled. Any clearer?
In Craig's example, he put a "send" statement in the handler script on mouseUp. When you clicked the button (as well as various other messages) it generated a mouseUp message. In the button script there is an "on mouseUp" handler, so the mouseUp message is dealt with. In this case, the handler created another message "displayMessage" and sent that to the message path to seek a handler. It just so happened that you made the "on displayMessage" handler in the same script, so it didn't have far to go in the message path before it got handled. Any clearer?
Re: Random message pops up but within constraints
Okay, I think I see what you mean.
So, say there are multiple handlers that are restaurants.
And you want chicken soup.
So you say, "Hey, I want chicken soup."
That request is sent to all the restaurants until one says, "Hey, yeah. We got chicken soup. We'll feed you."
Is that the right analogy?
So, say there are multiple handlers that are restaurants.
And you want chicken soup.
So you say, "Hey, I want chicken soup."
That request is sent to all the restaurants until one says, "Hey, yeah. We got chicken soup. We'll feed you."
Is that the right analogy?
Re: Random message pops up but within constraints
Kindof, lol, and the message path is the street full of restaurants you walk along until you find one with soup (handler) on the menu (script).
Re: Random message pops up but within constraints
Okay, this sounds crazy, but that analogy really helps me to understand the basic logic of what's happening. I think I get lost in the terminology which is clouding my understanding of the basic underlying process. I totally get that the terminology is critical, though.
Re: Random message pops up but within constraints
I just re-read this entire thread. I think it's starting to come into view...
Re: Random message pops up but within constraints
Okay, here's a question... It's from one of Craig's homework assignments...
It's about using custom properties to keep track of the number of the random number picks that have occurred during the loop.
So, let's say we want to only have a max of 10 picks and then the program exits the loop.
Conceptually, it's my impression that this is how this works:
1) Create a custom property that defines the maximum number of random "picks" that can be put into field 1 (let's say a max of 10 for this exercise) so, cMaxNumberCount = 10
2) With every random pick, a unit of 1 is subtracted from the max of 10
3) If the custom property reaches 0 then...
4) ...answer "You've reached your maximum of 10 numbers!"
5) Exit to top
I think "set" and "get" are used but I'm not exactly sure how.
It's about using custom properties to keep track of the number of the random number picks that have occurred during the loop.
So, let's say we want to only have a max of 10 picks and then the program exits the loop.
Conceptually, it's my impression that this is how this works:
1) Create a custom property that defines the maximum number of random "picks" that can be put into field 1 (let's say a max of 10 for this exercise) so, cMaxNumberCount = 10
2) With every random pick, a unit of 1 is subtracted from the max of 10
3) If the custom property reaches 0 then...
4) ...answer "You've reached your maximum of 10 numbers!"
5) Exit to top
I think "set" and "get" are used but I'm not exactly sure how.
Re: Random message pops up but within constraints
...Or!!!...
Is it like the custom property is a box? So it's like you have 2 boxes: One for the starting amount and one for the ending amount. Once all of the allotted number from the first box have been moved to the second box, the program is complete?
Is it like the custom property is a box? So it's like you have 2 boxes: One for the starting amount and one for the ending amount. Once all of the allotted number from the first box have been moved to the second box, the program is complete?
Re: Random message pops up but within constraints
You can control the flow of operations in many ways, and LiveCode is especially versatile compared to other languages in the number of ways it lets you tackle the cat-skinning process.
Thinking about your use, you want to be able to have a user choose some options. So a field seems like a good idea for now, it will let the user type something into the box that we will use to make a counter.
We can then read the value that the user put in the field and (after checking that it's a number in the right range) we can use that to control the loop. Yes you can subtract one from the count each time and exit when the counter reaches zero.
A property is somewhat like a variable in that it is a "box" containing a value. Where it differs is that it is attached to an object, and the manner in which you put things into and refer to the value. You could say that the volume is a property of your radio. You can "set the volume of the radio to 7". Or you can read the dial and see that "the volume of the radio" is 7. LiveCode objects all have properties, which are built in. For instance, you can "set the width of this stack to 800" where width is a built in property of the stack.
You can add all sorts of other properties that you define as well as the built in ones. These are, as you will have gathered, "custom properties". They can be called names of your choice similar to variables, and there is a convention to use a prefix c (for custom property) or u (for user-defined property) in the name. The custom property (just as with a built in) has to be a property OF something. So there is always a reference to an object when you get or set its value. Therefore, just as different fields all have a width of their own, you can set custom properties of the same name in multiple objects.
In this case you don't want to reuse it with multiple objects. So a suitable object may be the card. So yes, you can "set the cMaxNumberCount of this card to 10.
Depending on how you want to control the looping structure, you may or may not want to use a custom property at all. A loop can have its own counter and this might be dealt with using a variable. Custom properties are a good way of being able to store a value that can be interrogated from any part of any scripts you have in the stack, avoiding the use of global variables. For this reason it makes sense to think about a custom property to put the current time into when you click the button to start your script which should last for an hour and then exit. This property can then be reached from whichever handler you need to have check the elapsed time.
So... it's probably muddying the waters to give you all this, but thinking like a programmer is what it's all about. Decide on a way to deal with the problem and define the program flow. Then you can code the handlers to do the right things to make it work. Sometimes you may find that your program flow idea could be improved by doing it a different way, but on the whole, there is no "right" or "wrong" way. (But there are conventions and some ways are more efficient than others)
Thinking about your use, you want to be able to have a user choose some options. So a field seems like a good idea for now, it will let the user type something into the box that we will use to make a counter.
We can then read the value that the user put in the field and (after checking that it's a number in the right range) we can use that to control the loop. Yes you can subtract one from the count each time and exit when the counter reaches zero.
A property is somewhat like a variable in that it is a "box" containing a value. Where it differs is that it is attached to an object, and the manner in which you put things into and refer to the value. You could say that the volume is a property of your radio. You can "set the volume of the radio to 7". Or you can read the dial and see that "the volume of the radio" is 7. LiveCode objects all have properties, which are built in. For instance, you can "set the width of this stack to 800" where width is a built in property of the stack.
You can add all sorts of other properties that you define as well as the built in ones. These are, as you will have gathered, "custom properties". They can be called names of your choice similar to variables, and there is a convention to use a prefix c (for custom property) or u (for user-defined property) in the name. The custom property (just as with a built in) has to be a property OF something. So there is always a reference to an object when you get or set its value. Therefore, just as different fields all have a width of their own, you can set custom properties of the same name in multiple objects.
In this case you don't want to reuse it with multiple objects. So a suitable object may be the card. So yes, you can "set the cMaxNumberCount of this card to 10.
Depending on how you want to control the looping structure, you may or may not want to use a custom property at all. A loop can have its own counter and this might be dealt with using a variable. Custom properties are a good way of being able to store a value that can be interrogated from any part of any scripts you have in the stack, avoiding the use of global variables. For this reason it makes sense to think about a custom property to put the current time into when you click the button to start your script which should last for an hour and then exit. This property can then be reached from whichever handler you need to have check the elapsed time.
So... it's probably muddying the waters to give you all this, but thinking like a programmer is what it's all about. Decide on a way to deal with the problem and define the program flow. Then you can code the handlers to do the right things to make it work. Sometimes you may find that your program flow idea could be improved by doing it a different way, but on the whole, there is no "right" or "wrong" way. (But there are conventions and some ways are more efficient than others)
Re: Random message pops up but within constraints
(Aside) Sparkout, where have you seen a message name of more than one word? Am I being too absolutist?
Snappy.
You simply must read and play with the introductory materials.
I wrote that blurb because you had tried to:
send "This is your random number:" && random(99) to fld 1 in random(5) seconds
Though this made logical sense, it is syntactically a mess. You have to think of it like this: "What handler will this message be trapped by?" Handlers always are of the form:
on messageName parameterlist (where messageName is a single word, and a comma delimited list may or may not follow)
Could it be "This", with all the other words, including the result of a function call, sent as parameters. No way. For the moment let us keep it simple. When you write, in a mouseUp handler in a button, say:
beep 3
The "beep" is a command, and the "3" is a parameter. The engine understands "beep" and will gladly accept a "3" along with it. Just a little more advanced is to be able to write your own custom message and handler, as before:
send "myFirstMessage" && random(999) to this card
Livecode has never heard of "myFirstMessage", but it will take it on faith and search for a handler of that name. If it finds one, it will trap and execute it. The parameter is the result of the function call, and this is evaluated BEFORE the message is sent. So one possible message resulting from this line of code is that "myFirstMessage 456" is sent along the message path. When it finds the handler, the "456" is already attached. That handler then deals with it as it has been instructed to.
The homework you refer to, where you could find no benefit in the button script vs. the card script, must be reread. I wanted you to rewrite the handlers so that the random call could take place in either. You can do this.
Keep at it. I assume we will hear from you again.
Craig
Snappy.
You simply must read and play with the introductory materials.
I wrote that blurb because you had tried to:
send "This is your random number:" && random(99) to fld 1 in random(5) seconds
Though this made logical sense, it is syntactically a mess. You have to think of it like this: "What handler will this message be trapped by?" Handlers always are of the form:
on messageName parameterlist (where messageName is a single word, and a comma delimited list may or may not follow)
Could it be "This", with all the other words, including the result of a function call, sent as parameters. No way. For the moment let us keep it simple. When you write, in a mouseUp handler in a button, say:
beep 3
The "beep" is a command, and the "3" is a parameter. The engine understands "beep" and will gladly accept a "3" along with it. Just a little more advanced is to be able to write your own custom message and handler, as before:
send "myFirstMessage" && random(999) to this card
Livecode has never heard of "myFirstMessage", but it will take it on faith and search for a handler of that name. If it finds one, it will trap and execute it. The parameter is the result of the function call, and this is evaluated BEFORE the message is sent. So one possible message resulting from this line of code is that "myFirstMessage 456" is sent along the message path. When it finds the handler, the "456" is already attached. That handler then deals with it as it has been instructed to.
The homework you refer to, where you could find no benefit in the button script vs. the card script, must be reread. I wanted you to rewrite the handlers so that the random call could take place in either. You can do this.
Keep at it. I assume we will hear from you again.
Craig
Re: Random message pops up but within constraints
(aside) I have never seen a message name of more than one word. I was pointing out the difference between the message which is generated by the event and the handler which deals with it.
Re: Random message pops up but within constraints
Thanks, SparkOut. Thanks, Craig.
SparkOut: Thanks for showing the possible ways of tackling the problem. By trade, I'm a visual effects artist. I totally get that there's more than one way to get it done. And that some ways are more efficient than others. As I learn and look at others' approaches, I think I'll start to pick up on that.
Craig: Thanks for the information. Am I testing your patience?! Lol.
Sorry if I am. I actually am trying to tackle this via the provided Livecode materials, too. And even with the 10-Day trial of LCU. Not just through the boards. I'm finding that, for me, there's still a lot of very basic holes that I don't understand that I'm still trying to pick up on and that even after doing some of the examples, I'm still not clear on why or what I'm doing. That said, I'm staying on it. It'll eventually sink in. That's why, for me, the simple analogies help me to grasp the underlying concepts a little easier.
I've cut and pasted Craig's most recent message and annotated it just for the ease of conversation from here on...
>>
I wrote that blurb because you had tried to:
send "This is your random number:" && random(99) to fld 1 in random(5) seconds
>> Yes, I was following the form of the "put" statement from the earlier exercise. Newbie mistake. Still discovering what the underlying logic is...
Though this made logical sense, it is syntactically a mess. You have to think of it like this: "What handler will this message be trapped by?" Handlers always are of the form:
on messageName parameterlist (where messageName is a single word, and a comma delimited list may or may not follow)
>> Okay. I've not yet experienced parameters like that to my knowledge but I do understand the basic idea of a message followed by a parameter(s) that would be separated by commas
Could it be "This", with all the other words, including the result of a function call, sent as parameters. No way. For the moment let us keep it simple. When you write, in a mouseUp handler in a button, say:
beep 3
The "beep" is a command, and the "3" is a parameter. The engine understands "beep" and will gladly accept a "3" along with it. Just a little more advanced is to be able to write your own custom message and handler, as before:
send "myFirstMessage" && random(999) to this card
>> Okay, I see what you mean. Yes, my mistake earlier... "send" is looking for a message to follow it. Where as "put" is looking for a value or string of words to put into a field. Incidentally, "&&" means separated by a space, correct?
Livecode has never heard of "myFirstMessage", but it will take it on faith and search for a handler of that name. If it finds one, it will trap and execute it. The parameter is the result of the function call, and this is evaluated BEFORE the message is sent. So one possible message resulting from this line of code is that "myFirstMessage 456" is sent along the message path. When it finds the handler, the "456" is already attached. That handler then deals with it as it has been instructed to.
>> Got it. Though I understand there are best practices for naming conventions, messages are programmer-defined and flexible (within certain syntactical constraints).
The homework you refer to, where you could find no benefit in the button script vs. the card script, must be reread. I wanted you to rewrite the handlers so that the random call could take place in either. You can do this.
>> I'm not sure I couldn't find a benefit between the button script vs. the card script... I feel very sure there's a benefit to everything you guys have been helping me with. You guys have been great. Perhaps I'm misunderstanding the homework assignment?
<<
Thanks for your patience, guys. And double-thanks for your help. It's all very new to me but I'm usually a fairly quick learner. Once I can grasp the initial stuff, I think I'll be able to pick up speed.
Also, as I search around and try to learn through the other tutorials, etc., if you guys know of any one in particular that might help where I'm at, I'm game.
SparkOut: Thanks for showing the possible ways of tackling the problem. By trade, I'm a visual effects artist. I totally get that there's more than one way to get it done. And that some ways are more efficient than others. As I learn and look at others' approaches, I think I'll start to pick up on that.
Craig: Thanks for the information. Am I testing your patience?! Lol.

I've cut and pasted Craig's most recent message and annotated it just for the ease of conversation from here on...
>>
I wrote that blurb because you had tried to:
send "This is your random number:" && random(99) to fld 1 in random(5) seconds
>> Yes, I was following the form of the "put" statement from the earlier exercise. Newbie mistake. Still discovering what the underlying logic is...
Though this made logical sense, it is syntactically a mess. You have to think of it like this: "What handler will this message be trapped by?" Handlers always are of the form:
on messageName parameterlist (where messageName is a single word, and a comma delimited list may or may not follow)
>> Okay. I've not yet experienced parameters like that to my knowledge but I do understand the basic idea of a message followed by a parameter(s) that would be separated by commas
Could it be "This", with all the other words, including the result of a function call, sent as parameters. No way. For the moment let us keep it simple. When you write, in a mouseUp handler in a button, say:
beep 3
The "beep" is a command, and the "3" is a parameter. The engine understands "beep" and will gladly accept a "3" along with it. Just a little more advanced is to be able to write your own custom message and handler, as before:
send "myFirstMessage" && random(999) to this card
>> Okay, I see what you mean. Yes, my mistake earlier... "send" is looking for a message to follow it. Where as "put" is looking for a value or string of words to put into a field. Incidentally, "&&" means separated by a space, correct?
Livecode has never heard of "myFirstMessage", but it will take it on faith and search for a handler of that name. If it finds one, it will trap and execute it. The parameter is the result of the function call, and this is evaluated BEFORE the message is sent. So one possible message resulting from this line of code is that "myFirstMessage 456" is sent along the message path. When it finds the handler, the "456" is already attached. That handler then deals with it as it has been instructed to.
>> Got it. Though I understand there are best practices for naming conventions, messages are programmer-defined and flexible (within certain syntactical constraints).
The homework you refer to, where you could find no benefit in the button script vs. the card script, must be reread. I wanted you to rewrite the handlers so that the random call could take place in either. You can do this.
>> I'm not sure I couldn't find a benefit between the button script vs. the card script... I feel very sure there's a benefit to everything you guys have been helping me with. You guys have been great. Perhaps I'm misunderstanding the homework assignment?
<<
Thanks for your patience, guys. And double-thanks for your help. It's all very new to me but I'm usually a fairly quick learner. Once I can grasp the initial stuff, I think I'll be able to pick up speed.
Also, as I search around and try to learn through the other tutorials, etc., if you guys know of any one in particular that might help where I'm at, I'm game.
Re: Random message pops up but within constraints
Snappy.
There are several here who race to answer first. With that sort of crowd, I would not worry that asking too many questions is seen as excessive. It is a character flaw we are working on, and has nothing to do with you.
I wanted you to be able to make the "random" function work in either the button or card scripts, just so you could see the inherent flexibility of the message path. In this case, it affects functionality not at all. But there will come a time soon when you will see striking advantages to placing certain code setions in certain places. An understanding of the message path is essential in this phase of your understanding.
Your analysis above is, again, spot on and shows rapid insight into how LC works at its foundation. This is the sort of thing that will gel quickly, as we said. After that, it is just a matter of learning new words and techniques. That part is very straightforward.
Craig
There are several here who race to answer first. With that sort of crowd, I would not worry that asking too many questions is seen as excessive. It is a character flaw we are working on, and has nothing to do with you.
I wanted you to be able to make the "random" function work in either the button or card scripts, just so you could see the inherent flexibility of the message path. In this case, it affects functionality not at all. But there will come a time soon when you will see striking advantages to placing certain code setions in certain places. An understanding of the message path is essential in this phase of your understanding.
Your analysis above is, again, spot on and shows rapid insight into how LC works at its foundation. This is the sort of thing that will gel quickly, as we said. After that, it is just a matter of learning new words and techniques. That part is very straightforward.
Craig
Re: Random message pops up but within constraints
Thanks, Craig. Actually I'm thrilled that the board is as active as it is. I've been in other situations where it was tough to get a response. This is a breath of fresh air.
I totally see what you were driving at by demonstrating the different message paths. I actually just recently reviewed that so I could understand where you might want to have something at stack level, card level, object level, etc. In fact, I did an earlier tutorial where a stack-wide menu structure was built that utilized a grouping function. I definitely understand the value of passing messages upwards (or downwards...).
I totally see what you were driving at by demonstrating the different message paths. I actually just recently reviewed that so I could understand where you might want to have something at stack level, card level, object level, etc. In fact, I did an earlier tutorial where a stack-wide menu structure was built that utilized a grouping function. I definitely understand the value of passing messages upwards (or downwards...).