Shared script

[marielle]

scripts outside the message path would require a custom solution.

Surprisingly, it doesn't. The solution is very generic and no more than 50 lines of code.

Code: Select all

put resources.getRef("library","api_gesture") into tLibRef
send doSomething to tLibRef
put resources.getRef("widget","thisSpecificPanel") into tWdgRef
send view.refresh to tWdgRef
put resources.getRef("template","myNiceLayout") into tTptRef
copy tTptRef to this card

The major advantage is that if I want to reuse a panel or a part of an interface doing something very specific (this can be an image file preview widget for instance or the gesture detection pad I mentioned), I simply copy the onscreen widget onto a card. I copy the library object onto the library card of the resources substack. Job done. I can start using them straight away and everything works immediately.

[FourthWorld]

scripts outside the message path would require a custom solution.

Surprisingly, it doesn't. The solution is very generic and no more than 50 lines of code.

I didn't say it would necessarily be long, merely that it would require a custom handler, such as the one you've written to handle your specific setup, to determine which controls are being used as virtual libraries and which ones are just controls.

[FourthWorld]

Also, one difficulty in using "send" to route messages to scripts outside of the message path is that it's quite slower than the natural message path. For occasional use the performance penalty of "send" isn't much, but I tend toward solutions that go with the grain of the message path whenever possible, saving any extra clock cycles for features.

I didn't benchmark this. I never had any reason for concern.

Feedback from Dar suggested the cost was really minimal. Do you have any data on this yourself?

Comparing "send" vs. the natural message path shows the former to be only twice as slow, and "minimal" is relative since we're talking 0.004ms vs 0.002ms (see test script with results below). Used occasionally, the impact of "send" will probably never be noticed, but if used throughout heavily-accessed portions of a program it can add up.

My main point wasn't that "send" isn't useful; indeed it's been in the language since HyperTalk because it can be very useful at times.

But most importantly what I wanted to convey for newcomers is merely that while there's an infinite variety of ways to solve problems with Rev, there isn't really anything inherently wrong with the natural message path. It's been used quite effectively in hundreds of commercial products developed by teams from 1 to 25 team members. FrontScripts, backScripts, and libraries are all supported natively in the engine; they're fully tested, robust, and efficient means to satisfy Tom's request.

Here's the benchmark script I used to test the message path vs "send", "do", and getProp:

on mouseUp
put 100000 into n
--
-- Native message path:
put the millisecs into t
repeat n
doMe
end repeat
put (the millisecs - t)/n into t1
--
-- Send:
put the millisecs into t
repeat n
send "doMe" to btn 2
end repeat
put (the millisecs - t )/n into t2
--
-- Do:
put the millisecs into t
repeat n
do "doMe"
end repeat
put (the millisecs - t)/n into t3
--
-- getProp:
put the millisecs into t
repeat n
get the uWhat of this cd
end repeat
put (the millisecs - t)/n into t4
--
--
set the numberformat to "0.000"
put "Native: "& t1 &"ms" &cr\
&"Send: "&t2 &"ms" &cr\
&"Do: "&t3 &"ms" &cr\
&"Prop: "&t4 &"ms"
end mouseUp


The script depends on a button named "class" with this script:

getProp MyTest
return 4+4
end MyTest


And this script in the stack:

function MyTest
return 4+4
end MyTest

function MyObj
return the long ID of btn "Class"
end MyObj


The results I get here are:

Native: 0.002ms
Send: 0.004ms
Do: 0.004ms
Prop: 0.003ms

[marielle]

Hi Richard,

I had missed that one out for some reason. Many thanks for these data.

Marielle