What to return when there is no return?

[Clarkey]

Hi folks, If building a library function that doesn't return a specific response to a calling script - for example, where the function updates a custom property - is there any best practice concerning what should be returned to the calling script to indicate the function's completion and hence, prevent the calling script from hanging?
Best,
Keith..

[bn]

Hi Keith,
if I get you right:
you could either do some error checking in the function (if condition then return "OK") and test in the calling script for "OK" or if you dont want to return anything make it a command in your library, not a function.
A command does not return anything. So you just call the command, the script executes the command in your library and then continues.

Code: Select all

on myScript
...
myLibraryCommand
...
end myScript

on myLIbraryCommand
do stuff
end myLibraryCommand

Or do I misunderstand something?

regards
Bernd

[Clarkey]

Hi Bernd, Thanks for responding and clarifying the difference between a called function and called command, which is really useful to know.

My library has two distinct types of method that seem to fall into your function and command categories:
1. Functions: I would use these, returning a 'finished' indicator, to manage outbound SOAP message, which take time and I need to ensure that they have completed (generally updating some kind of variable or array placed in a custom property) before the calling script attempts to act on the response to the SOAP call.
2. Commands: I would use these 'blind' calls for local actions, such as pulling data from a custom property array into a data grid.

I guess that in either case, if necessary, I can create a 'repeat until' loop in the calling scripts, with a wait timer, to check the return value or result of the command.

I take it that the choice of 'finished/OK' return is mine - there are no naming conventions associated with return variables(?)
Best,
Keith..

[bn]

Hi Keith,

I take it that the choice of 'finished/OK' return is mine - there are no naming conventions associated with return variables(?)

You are free to return what you want, I don't know of any naming convention.
For a function the result and what you return is the same. A command does not return anything but if you add

Code: Select all

return "error"

to a command then in the calling script you can test for "the result" if something went wrong.
Look up "result" in the dictionary
here is a script that shows the difference, 1 field 1 button. Once with the optionKey down (or AltKey on Windows) and once without.

Code: Select all

on mouseUp
   if the optionKey is down then  -- on windows the altKey
      put myFunction() into field 1
      put return & the result after field 1
   else
      myCommand
      put the result into field 1
   end if
end mouseUp

function myFunction
   return "GoodDay"
end myFunction

on myCommand
   return "good Day through result"
end myCommand

1. Functions: I would use these, returning a 'finished' indicator, to manage outbound SOAP message, which take time and I need to ensure that they have completed (generally updating some kind of variable or array placed in a custom property) before the calling script attempts to act on the response to the SOAP call.
2. Commands: I would use these 'blind' calls for local actions, such as pulling data from a custom property array into a data grid.

sounds perfectly allright. Just make shure that you add a "wait X unitOfTime with messages" in the repeat loop to let Runrev do its behind the scene maintenance.

regards
Bernd

[Clarkey]

Hi Bernd,
That's great - thanks for the tips!
Best,
Keith..