During the day, I spend time in Progress OpenEdge ABL, Java and revTalk -each language has its own degree of object-orientation. So let me see if I can make a good comparison for you...
revTalk is object-based but not object-oriented. There is a limited set of base objects: button, field, scrollbar, graphic, image, group, card and stack. You can only inherit 1 level deep from these base objects to specialize them, and then you cannot override their paint or draw method. This may sound extremely limiting if you're used to squeezing every last bit out of Java or C# - but the underlying framework with its ChainOfCommand implementation (
message path in rev parlance) and plain english programming language more than make up for the limitations.
In fact, given the recent evolution in OO programming towards
DCI (Data-Context-Interaction with 'dumb' data objects and 'roles' to express the business logic in an almost-proecdural way) you could say that the way rev works better matches our 'natural' way of thinking than off-the-shelf Java. Once you get past the initial hurdles and learn to appreciate the rev paradigm, you can become very productive.
Anyway, enough programming philosophy
You've already discovered how to add methods in a script, writing
on,
command, and
function handlers. Property handling is quite open: any script can set any property on another object, so if you want to check their content upon set or add a property that returns a combination of fields, you'll have to do that by writing
setProp and
getProp handlers.
If I give a button "TestObject" the following script:
Code: Select all
on mouseUp
beep the uBeepTimes of me
answer FatFirstLine(the uAnswerText of me)
end mouseUp
function FatFirstLine pText
local tIndex, tReturnText
put 0 into tIndex
repeat for each line tLine in pText
add 1 to tIndex
if tIndex = 1 then
put "<p><b>" & tLine & "<b><p>" after tReturnText
else
put "<p>" & tLine & "<p>" after tReturnText
end if
end repeat
retutn tReturnText
end function
setProp uBeepTimes pNewBeepTimes
if pNewBeepTimes is not an integer or pNewBeepTimes is < 1 then
throw "uBeeptimes must be an integer >= 1"
end if
-- it is ok, so allow the property to be set
pass uBeepTimes
end uBeepTimes
You can change the number of times it beeps, and which text it displays, by setting its uBeepTimes and uAnswerText properties:
Code: Select all
set the uBeepTimes of button "TestObject" to 9
set the uAnswerText of button "TestObject" to "Hello, world!" & return & "Every day that you learn something new, is a wonderful day..."
Click the button and it will obey.
But if you try to set the uBeepTimes property to something wrong:
Code: Select all
set the uBeepTimes of button "TestObject" to "smurf"
an error will be thrown, and the new property content is not set.
So you can always write objects that are, in fact, invisible controls. If you need containment, you can create a group with tis own script, and then other controls inside that group. It is stretching things a bit, as you'll still have to refer to these custom objects as 'group "Order_1"' with its 'button "OrderDetail_12"' but it is one way to accomplish custom objects.
It would take up too much time to explain everything in minute detail, but now you have some ideas on how you can 'specialize' existing objects. Make sure to read this
excellent article on the message path. Many people also adopt this
scripting style guide for organizing their scripts.
HTH,
Jan Schenkel.
