On 25 Mar 2006, at 19:07, J. Landman Gay wrote:
Okay, I'll bite. I have just created your version 1. I have not
looked at version 2 yet.
Here is my setup:
1 button: Choose
3 flds: BaseFolder, FolderContents, FileContents
These controls were grouped. No name or custom properties were
assigned to anything. I set the listBehavior of the FolderContents
field to true, and put vertical scrollbars on FolderContents and
FileContents. Setup time: about 1 minute.
Setting up the controls so they look nice will be the same and will
depend on what the customer wants. I'm happy to say this is even.
Scripts:
** Choose button:
on mouseUp
answer folder "Choose the base folder:"
if it <> "" then setFolder it
end mouseUp
** FolderContents field:
on selectionChanged
putFileContents (the selectedtext of me)
end selectionChanged
** Stack script:
on setfolder tFolder
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
Ok the actual gathering of the Files in a Folder is handled in my app
was handled in a Library Stack so the code necessary to do this is
not duped all over the place. You could do the same so the time taken
to code this would be roughly the same. The same goes for getting the
file contents.
on putFileContents tFile
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
end putFileContents
Ok, but you are hard coding control names which I was trying to
avoid. For instance If the customer didn't want the path of the
folder displayed anymore (e.g. there was just a choose button) then
all I'd have to do is to delete the field. Using the method above
you'd have to change the script otherwise you'd get an execution
error. The same goes for any field, using ISM deleting a control
stops the action initiator from sending to that control (since they
no longer are "listening"). I guess you could prefix all control
accesses with an "if exists() then" clause but this gets cumbersome
and adds additional overhead. Also if the user wanted the folder path
displayed in a number of places (say in different card(s) or even in
different stack(s)), you'd have to change the script, whereas I'd
just have to copy and paste the existing Folder Path name field and
it would automatically pick up the folder when it was selected.
Also with my method I can paste in a control from another group and
it will instantiate itself automatically and since there are no hard-
coded control names you don't get any execution errors.
Also if you wanted these groups in another stack you'd have to paste
the groups and then paste the Stack Script. If you already had
handlers with the same name in the Stack Script you'd have to do some
jiggerling in order to make it work.
With my method when
Comparing our methods:
Thing Mine Yours
# of objects with scripts 3 8
# of custom properties 0 3
# objects with custom props 0 8
Total lines of script 21 63
Point taken about the number of Scripts, but bearing in mind the
above flexibility, I'd rather have more scripts and not have to
change things in other scripts. I could cut down on the number of
scripts and sacrifice flexibility by "Listening" at a higher level.
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
