Thanks, mikesart, for that macro. I'm using it now, with a number of tweaks (attached).
Most notable:
- Fixed case sensitivity in the hash array; systems with case insensitive filenames needed a tweak.
- Converted the project dir list definitions to be a data table (array) rather than code; this will help if/when this macro is enhanced to allow runtime user configuration of the project dir lists.
- Expanded the default set of file extensions, and added (expandable) shorthand notation for multiple default sets of file extensions (<sources>, <headers>, <slick>, etc).
- All dir list entries support file spec lists (rather than requiring a separate dir list entry per explicit wildcard).
- Expands env vars in directories.
- Added some performance notes; will follow up on them later.
Your project dir lists should all be intact inside the #define MIKESART sections. Mine are in the #define CHRISANT section. Other users can replace those with their own list of project dir list definitions. Hopefully I haven't broken anything for platforms with case-sensitive file systems.
@SlickTeam: The project support in SlickEdit is great. However, setting up the file list for a project could be improved quite a bit (I gather that's already on your wish list). Currently we have to choose between (1) entering lots of individual wildcard entries (and exclusions, oh my) and getting poor performance for large projects (due to scanning the file system once per session), or (2) manually updating the project file list (have to know/remember the paths and long lists of extensions, and exclusions, and iterate through them manually) but getting good performance for large projects (loads a cached file list rather than scanning the file system). This macro is a simplistic compromise between (1) and (2), but the capability in this macro (or something better
should ideally be built into SlickEdit. This macro still has a drawback in that it runs in the foreground, so for large projects it is still expensive to run, but at least we can control when it runs. I'd be happy to discuss more about project definitions for large projects (20k+ files, 10-30 wildcards, exclusions, supporting tag files, etc) further in the forums or in private emails if/when you want to enhance the project file list support (you have my email address). In the meantime, this macro is pretty good workaround (albeit with part of the project definition living outside the actual project file), so it's not like we're dying without project enhancements.
Thanks,
Chris