Page 1 of 1

FileLister.rev design question

Posted: Wed Jan 09, 2013 11:38 am
by Simon Knight
Hi,
I am basing a utility application I am writing on the example stack provide by RunRev named FileLister.rev. I am curious why certain handlers have been written and wonder if there is a hidden reason for them being there.

The stack has a single card with some buttons and two fields. The first field displays the path to a folder that the user selects and the second displays a list of files that are in the folder (less those with names starting with points). The routine that builds the file list is passed parameters one of which is the file path to the folder. What I find odd is that instead of just passing the contents of the field on the card the author has chosen to write a handler that returns the contents of the field as shown in these code snips :

Code: Select all

function currentFolder
  return the text of field "Folder" of me
  put empty into field "Result" of me
end currentFolder

function currentRecurse
  return the hilite of button "Recurse" of me
end currentRecurse
A button named list files has the following code which calls the handler that lists the files :

Code: Select all

on mouseUp
  put listFiles(currentFolder(), currentRecurse()) into field "Result"
end mouseUp
While this may simplify the main call I think that this structure is over complex and makes the code harder to read and understand especially as the routines are split between the card and stack scripts.
I would have written :

Code: Select all

on mouseup
   put the text of field "Folder" of me into tpath
   put the hilite of button "Recurse" of me into tRecurse
   put empty into field "Result"

   put listFiles(tpath, tRecurse) into field "Result"
end mouseup
doing away with the two routines listed above. What do you all think?

Re: FileLister.rev design question

Posted: Wed Jan 09, 2013 12:34 pm
by Klaus
Hi SImon,

sounds like a "personal scripting" style to me, so if your script is working, don't bother to
try to understand the intentions of the original scripter, which has an error in the
first function anyway, it will NEVER put empty into fld "Result"! :D


Best

Klaus