What's with "the result" ??

[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?

Code: Select all

put the result into temp

[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

[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.

[FourthWorld]

Good stuff, Sparkout.

I use a very similar approach:
http://livecodejournal.com/tutorials/ha ... s-001.html

[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

[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.