View Single Post
Old 01-05-2012, 02:29 AM   #9
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 2,989
Karma: 18346231
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
Quote:
Originally Posted by bogomil View Post
It will be very handy if in -f <dir> [ext]:
- the directory (optionally) can be selected interactively with OpenDirectorySelector;
- introduce an additional option - traversing subdirectories or not;
- introduce an option for filtering the filenames;
Thanks for the nice toolset
As far as the first point goes, I think you can just run the OpenDirectorySelector first with a proper message for the user, and then use the output from that with the "-f" option next. At this point, merging them would add a fair bit of complication (can't just CloseApp() after the dir is picked, have to handle an optional message to the user for directory selection, have to know how to handle the user bailing out of the directory selection,...), and complication == bugs when I'm writing the code.

The other two points would be useful and can't be worked around as above, so I agree that they should go in. I think the whole "-f" option argument structure will have to be reworked for that.

Thanks for the helpful input.
rkomar is offline   Reply With Quote