getProp & setProp confusion

[gyroscope]

Hi, I'm revisiting getProp and setProp in the Users Guide, and I'm a bit confused (nothing new there )

I tried a li'l test stack with the example given, and assumed that to obtain the returned value would be the same principle as for functions. So the first handler is mine, and the getProp is the User Guide example:

Code: Select all

on mouseUp pMouseBtnNo
   put myCustomProperty() into field "B" 
end mouseUp

getprop myCustomProperty
return the vscroll of field "Field" + 20
end myCustomProperty

This doesn't work; have I misunderstood something?

While on this subject, I don't understand setProp at all; for instance, the example given:

Code: Select all

setProp myCustomProperty newSetting
set the hilite of me to true
pass myCustomProperty
end myCustomProperty

is fine but why not just put it in a straightforward mouseUp handler, which takes up less code?

Code: Select all

on mouseUp
set the hilite of me to true
end mouseUp

Also, I'm unclear why the line "pass myCustomProperty" is there.

Similarly with some simple functions: the User Guide example:

Code: Select all

function currentDay
return item 1 of the long date
end currentDay

Why not just

Code: Select all

on mouseDown
put item 1 of the long date into field "Field"
end mouseDown

instead of the above function, then more code to "call it up"?

Any light shed within this foggy room appreciated thank you!

[BvG]

set/getProp work on properties, and have ot be in the message path of the object that you set the property of. They're not functions you can call form everywhere:

so the first example should look somewhat like this:

Code: Select all

on mouseUp
   put the myCustomProperty of me into field "B"
end mouseUp

getprop myCustomProperty
  put the vscroll of field "Field" + 20
end myCustomProperty

for the various ways to exit handlers:

return yourValue:
if it's a function, then this will be the return value of the function, otherwise it'll be put into the special property "the result". This is especially useful if your handler is very long, and hard to read, or if you want to use the same code from various different places.

example:

Code: Select all

on mouseUp
  put myCalculator(10)
end mouseUp

function myCalculator theValue
  add one to theValue
  return theValue
end myCalculator

[BvG]

ah right, forgott "pass":

This has to do with the message path. Normally a handler will be sent to the target, and then up the message path, until it is "trapped" by it's correct handler. But sometimes you do want to pass it on, to do another thing further up the message path, or the engine. A very good example is the "shutdownRequest" message:

Code: Select all

on shutdownRequest
  answer "do you really want to shut down" with "cancel" or "quit"
  put it into myAnswer
  if myAnswer is "quit" then
    pass shutdownRequest
  else
    --quitting will be canceled by doing nothing here
  end if
end shutdownRequest

[gyroscope]

Hi BvG, that's excellent, thank you for the info. I'm learning, slowly but surely...

[SparkOut]

Hi gyro,
When it comes to conceptualising the "esoteric" features like getProp and setProp, it helps to be able to see under what circumstances you might feel a need for it. I often feel I don't understand something until I have worked out "ah, that's what that could be useful for."

This thread http://forums.runrev.com/phpBB2/viewtop ... =8146#8146 has a snippet at the bottom (although you might need to read the whole thread to see why the subject cropped up) which shows a (pseudo) real usage of virtual properties. It won't be terribly useful, but it may help to visualise how you can use virtual properties just like you would a built in property. Simply setting and getting the properties can generate the results you need, sort of like a function that enhances the Rev environment. It might help - if it confuses instead, then let me know and I'll try and explain better.

[gyroscope]

Thanks SparkOut, that's useful if still a bit confusing to me. (Although I looked at the post at 11pm so my brain isn't totally in gear; I'll have another read tomorrow).

Your comment of "ah, that's what that could be useful for" is definitely the right approach, I think. In other words, I'll cross the get/setProp bridge properly when it eventually clicks as to what their advantages are.

There was one surprising piece of information which I didn't realise was possible, once I had read the thread (that rhymes!); a setProp handler calling up a function.

[Mark Smith]

Imagine a substack called "sub" (so not in the message path from the mainstack) that has two fields: "num1" and "num2", both of which contain numbers.

Let's say we sometimes need to get the sum of the two fields from a handler in the mainstack.

We could do this:

put fld "num1" of stack "sub" + fld "num2" of stack sub into tTotal.

Or, we could have a getprop handler in the script of stack "sub":

getprop total
return fld "num1" of me + fld "num2" of me
end total

then in out mainstack handler we can do

put the total of stack "sub" into tTotal.

So what we have is a 'dummy' property of the substack.

Which method to use would depend on circumstances, but it's useful to have the choice.

for instance, if we needed that total in many handlers outside of the substack, and then we decided to add a third field that needed to be included in the total, we'd have to change every handler that used the first example, whereas in the second, we could just change the getprop handler in the substack, and be done.

This is a form of "encapsulation", and can be a really good time (and error) saver.

[gyroscope]

Excellent explanation Mark, thank you. It's sinking in now.