Page 1 of 1
What's with "the result" ??
Posted: Thu Jun 09, 2011 7:10 pm
by townsend
the result is a very unique phrase in LiveCode.
I've been using
the result after database commands, to check for errors.
But I see from the Dictionary that, it can be used after any command,
to check for an error. A return of empty means successful execution.
But how do you check it? Usually, moving the cursor over a field name,
displays its current value. (nice eh?) Or-- of course-- we can also check
the Variables List at the bottom of the Script Editor. BUT--
the result
shows up in neither! So when debugging, in order to check the value,
I always end up putting in this line of code in, which allows the cursor
over to display the value. Is there a better way?
Re: What's with "the result" ??
Posted: Thu Jun 09, 2011 9:28 pm
by dunbarx
From way back in HC days, the result is set after some command was executed, for example, find. It is a function, and returns a value, hopefully empty
So it is a function automatically, tacitly, and sort of behind the scenes, invoked with certain commands, I always put it into a variable, or deal with it directly. You have to check it in a script. But you certainly could write a bit of code to modify some other aspect of your work that might be checked as you wish.
Perhaps as a tooltip? Get the result, set a tooltip property based on your own criteria, and go.
Craig Newman
Re: What's with "the result" ??
Posted: Fri Jun 10, 2011 9:13 am
by SparkOut
the result is very versatile - but very volatile. It is a sibling to the "it" utilitarian variable. In most cases the distinction can be very crudely described as "it" containing a value returned by a funtion, and the result (maybe) containing a value describing the operation of the function (especially an error).
A classic example is
Code: Select all
answer file "Where is the file?"
-- the result will be empty most times, or will contain "Cancel" if the user clicked the cancel button
if the result is not "Cancel" then
-- the result was not cancel, so "it" is not empty and will contain the file path chosen
-- save "it" into a variable we can use, "it" will not have the same value for long!
put it into tPath
-- do stuff with tPath
end if
Depending on the option for breaking things, if you know the expected context for "the result" (say for revExecuteSQL it will hold the number of affected rows, or otherwise an error string) you can make a command to do some verification
Code: Select all
on checkTheResult pResult
if pResult is not an integer then
-- start alarm bells, because revExecuteSQL will return either an integer or an error string
showErrorMsg pResult
end if
end checkTheResult
on showErrorMsg pResult
answer error pResult
exit to top
-- or perhaps other graceful error handling like db connection closure, or...
end showErrorMsg
These handlers will lose whatever was returned in "it" in the original function, of course. You could deal with "it" first, or expand the result checker to take the "it" value along with it for other testing, or however you want to deal with it.
Re: What's with "the result" ??
Posted: Fri Jun 10, 2011 12:59 pm
by FourthWorld
Re: What's with "the result" ??
Posted: Fri Jun 10, 2011 11:29 pm
by dunbarx
What we are all saying is that it comes into play at very specific times, is incredibly useful when it does rear its head, and that you should grab it as soon as possible.
Craig Newman
Re: What's with "the result" ??
Posted: Sat Jun 11, 2011 12:05 am
by townsend
Thanks Craig! Now I understand. Also-- appreciate the code suggestions.
I like SparkOuts summary.
The result is very versatile. A sibling to the "it" utilitarian variable. In most cases the distinction can be described as "it" containing a value returned by a funtion, and the result (maybe) containing a value describing the operation of the function (especially an error).
Also, Richard's Tutorial:
Err - a generic error handler
This is a good thread for anyone else who's interested.
And, finally I found some good specifics in the Dictionary.