On 25 Mar 2006, at 19:50, J. Landman Gay wrote:
I've done version 2. It took me longer to figure out your scripts
than to write my own. Total scripting time was actually about ten
minutes, the rest was in trying to decipher yours so as to figure
out what I needed to do.
Ok! That's usually the case in my experience!
Using ISM all I had to do was this:
1. Copy and Paste the existing groups in question -
Group_SelectFolder, Group_SelectFile and Group_FileContents so
there were now two of each.
2. Arrange the new groups nicely in the window.
3. Change any user visible text to read A and B as appropriate.
4. Change the custom properties "cpFolderKind" and "cpFileKind"
so that the new groups now read FolderKindB and FileKindB.
That's all I needed to do to get the basic functionality of having
2 x Base Folders, 2 x FIle Lists and 2 x File Contents working.
(I repeated this action just now in a test stack and it took less
than 5 minutes).
I did exactly the same thing, but I didn't need to do step 4
because my method uses no custom properties. I option-dragged the
existing group to create a duplicate. Took 2 seconds, and that is
all that was required.
I didn't know about option-drag! Thanks!
With this working, I needed to add a new Group to do the compare.
The pseudo code for this (very close to the real code) is shown
below marked as Version 2.
I only added a single button, not in any group, called "Compare".
It has a one-liner script:
on mouseup
compareFiles
end mouseup
I didn't need to put it into a group either, I could have just added
a single button.
After that, all I needed to do was alter the master stack script. I
needed to add 1 line to the existing script, and add two new
handlers and a constant. Here is what I did:
constant kCompareNumber
on setfolder tFolder -- this one is unchanged
put the ID of the owner of the target into tGrp
put tFolder into fld "basefolder" of grp ID tGrp
put the directory into tOldDir
set the directory to tFolder
put the files into fld "folderContents" of grp ID tGrp
put "" into fld "fileContents" of grp ID tGrp
set the directory to tOldDir
end setfolder
on putFileContents tFile -- added 1 line at end
put the ID of the owner of the target into tGrp
put fld "basefolder" of grp ID tGrp & slash & tFile into tFilePath
put url ("file:"&tFilePath) into fld "fileContents" of grp ID tGrp
set the enabled of btn "Compare" to (the number of items in \
validFlds() = kCompareNumber)
end putFileContents
on compareFiles -- new handler
put validFlds() into tFldList
if the number of items in tFldList <> kCompareNumber
then exit compareFiles
repeat for each item i in tFldList
set the hilitedlines of fld id i to calcCompare(tFldList)
end repeat
end compareFiles
function validFlds -- new hander
repeat with x = 1 to the number of grps
if there is a fld "fileContents" of grp x and fld
"fileContents" of grp x <> ""
then put the ID of fld "fileContents" of grp x & comma after
tFldList
end repeat
delete last char of tFldList
return tFldList
end validFlds
Because these handlers are all in the same script, changing it
affects all existing groups and any new groups that are cloned from
the existing. I have made the new handlers extensible so that you
could compare 3 or 4 or any number of text fields simply by
changing the number of items required, which is stored in the
constant kCompareNumber.
Ok, I get your point about cloning and having the "master" script
inherit, it's true you lose some of this by using ISM, but I think
that the flexibility you gain is worth it.
You didn't show the actual handler that compares the files, but
that's okay, presumably mine and yours would be fairly similar and
do the same thing, so we don't have to consider that in our
comparison.
Agreed, my compare routine is actually in a Library Stack and it
takes 2 files as input rather than comparing the contents of a the
fields.
I didn't have to change anything in the existing groups, and my
scripts are (to my eyes, anyway) easier to follow and debug later.
They are much shorter. They don't require any custom properties or
special treatment.
I didn't 100% need the custom properties, it just seemed better
practice to do it that way.
Seems easier to me, but maybe I'm just too used to the xtalk
paradigm. By comparison, your way looks complex, difficult to
debug, and there are scripts in so very many places that following
the messaging path in a debugging session seems harder than it
really has to be. Again, maybe it's just my own perception.
In this case I'd agree that debugging may be slightly easier, but on
a more complex app I'd say my method is easier, since you can easily
trace a message path.
It's been an interesting exercise for a Saturday afternoon, thanks
for the opportunity. I'll bow out now.
Agreed! Thanks for taking part!
All the Best
Dave
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
