SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Slick-C® Macro Programming => Topic started by: asandler on November 14, 2007, 11:42:30 AM
-
Here's another macro. This one, once triggered, opens list of all project file. The list is search-able, like in open local symbol macro (http://community.slickedit.com/index.php?topic=2245.0). Note that older version of open local symbol WILL NOT work with this macro. Hence the new version of open local symbol. Have fun!
-
One important note. Thanks to hs2 for inspiring me to fix old abandoned macro and bring it to daylight ;D ;D ;D
-
Hi Alexander, it's really good to read this kind of feedback !!
And as already mentioned it also helped me to get a long missed feature and to get better in Slick-C programming too.
Because I'm using it very, very often I didn't stop to improve 'ols'...
(Added 'Quick tag filter' + Preview TB support and it scales much better with buffers containing a large number of tags.)
But there were quite a lot of internal changes so I need to do some more testing (simple enough - I'm just using it).
I've to say that I learned a lot again since I've done some of the things the first time.
I'll post it here when it passed (my own) QA and I've finished a short description to be prepared for the new 'User Macros' list/board/whatever ;)
Stay tuned,
HS2
BTW: I don't want to get in conflict with your versions - any idea about a proper naming scheme ?
-
Oh.. it's getting messy. In general I'd like to keep single branch of both macros. They are simply too small to make several different versions. Also, you'll need changes that I made in ols3 to run opf3. I suggest that you pick changes from ols3 (diff ols2 ols3 - there are not so many of them) and merge them into your version of the macro. How about that?
-
Ok Alex - I've checked the diffs and it should be pretty easy to merge/resolve the 'namespace' conflict.
Oh my - after I've finished the version which could handle a large number of tags better (in UI) I've realized that there is already a probably even better (undocumented) method available ...
Tested it and now I know that this is the way to go. It's really blazing fast even for large tree lists and also simplifies the code. This would speed up 'opf' as well. I'll send you an example howto use it after finishing the changes.
HS2
Edit: My bad - the super-fast method filters the caption only but this makes not much sense for 'ols' b/c we don't want to get argument list matches...
-
Latest open_local_symbol release by hs2 from here
http://community.slickedit.com/index.php?topic=2245.30
has no conflicts with open_project_file macro. Therefore, open_project_file3 is void. Please find attached "without '3'" version of the macro. It also includes nice copyright notice ;D and distributed as hotfix (credit goes to hs2 ;D) From now on, please download this version of the macro.
-
I really like this macro, but it doesn't work as-is for me. It assumes that the files in the project share a common root path with the project file. I keep my project files in a separate directory and so this doesn't work. For now I've hacked it to just prepend the drive letter part of the project file path to the file path.
-
I see. Thanks for reporting this. Give me few days and I'll fix it for you.
-
Finally got some time to work on it. Sorry for delay.
I think I fixed the issue you reported. Please give this new version a try.
Thanks.
In general, this is the latest version of the macro and is the version that should be downloaded.
-
I gave the new version a try but it doesn't fix the issue.
The problem is here: (~line 355)
name = _TreeGetCaption( index );
proj = _project_get_filename();
proj = strip_filename( proj, "N" );
name = proj :+ name;
This assumes the path part of the project filename can be prepended to the relative path of the file to get the full path. The problem is, my project files are not in some parent directory of the source files. So, for example:
My project file is here: c:\projects\oob
My source files are here: c:\source\test\test.cpp
The code above tries to open: c:\projects\oob\/source/test/test.cpp
Thanks!
-
You are right. My tests were incomplete and I missed this point. I fixed this in a new version and hope that it will work now. Sorry for the inconvenience and thanks a lot for pointing this spot.
This version supersede any previous versions of the macro.
-
It works perfectly now!
Thanks for fixing this and creating this very useful macro in the first place!
-
I found another bug in the code. Sometimes, depending on the slickedit's current directory, it wouldn't open the file. I fixed it and it should now work well. Please use this version if you experience the problem I described.
This version supersedes any previous versions of the macro.
-
Finally, as promised, my macros for SlickEdit web-page:
http://www.alexandersandler.net/stuff/software-projects/slickedit-macros
-
Congratulations - it's an absolutely great web site ! HP++
HS2
-
Asandler/hs2,
This is a fantastic macro.
Thank you both!
-
Hello all.
I brewed a new version of the open project file macro - version 1.0.7.
-> This version supports SlickEdit 2008.
-> It is more responsive thanks to new internal timer mechanism (@hs2 thanks for help).
-> It won't crash on you when working with big projects.
-> It understands slash symbol, thus you can do searches like aaa/bbb to make it look for file named bbb in directory named aaa.
-> I fixed a bug that caused inaccurate search results (adding one extra not matching file name for every search).
You can grab it on my web-site: http://www.alexonlinux.com/stuff/software-projects/slickedit-macros
Alexander.
-
Found a bug in 1.0.7 that caused backspace not to work properly.
Version 1.0.8 below fixes this.
Have fun!
-
Using v1.0.8:
I'm having trouble invoking the _open_project_file command: it says either "unknown command" or "invalid number" for all of the following: _open_project_file, -open-project-file, open_project_file, open-project-file. In the completion list it shows -open-project-file, but that results in "invalid number". When I use Macro->Open Form and choose open_project_file and then Load and Run, then the form comes up and seems to work.
However, when I typed "don" it restricted the list to things that matched "do" but included several things that did not match "don". When I typed Backspace, then it restricted the list to things that matched "don". So I think Backspace still isn't working right at the moment, nor is normal typing.
What features (besides newly recognizing the / character) does open_project_file have over the built in Files toolbar? I have a todo item on my list to make the Files toolbar support matching the FILESEP and FILESEP2 characters (basically I plan to change it so it compares against the full path instead of only the file name, and append "[^"_escape_re_chars(FILESEP:+FILESEP2)"]" to the end of the needle string; modulo whatever tweaks are needed to work successfully ;)).
-
@chrisant: Be aware that the Files TB uses a super-fast DLL function _FilterTreeControl() to do the filtering.
For large scale projects it makes a BIG difference in comparison with using the Slick-C macro code (which is still there but #ifdef'd). Maybe it's a good idea to send a feature request regarding an enhancement of this function.
HS2
-
@chrisant
First, don't try to load it via command line (i.e. SE's command line) or Macro->Open Form. The right way is to assign a keyboard shortcut to -open-project-file.
As for problem with "do"s and "don"s, can you please bit a little more specific. Can you please post names of the files in your project - this will allow me to reproduce the problem and fix it. What was the search pattern you used and what is the result you expected to see. Also, what version of SlickEdit you have?
The idea behind this macro and its main feature is to let you find file-name when you know only part of the file-name and perhaps part of the path to the file relative to project root directory. For example. Let's say you have a file blah/boom/foo/file.c you know that its name is "file.c" and that it is somewhere in blah directory. This is a very common situation with large projects. Using macro you can type in "blah file" and it will locate every file named ".*file.*" located in directory matching ".*blah.*".
The actual '/' character translated into space, so "blah file" and "blah/file" will produce exactly same results. Instead I match last word in the search pattern against file names while earlier words are matched against names of directories in the path (have to mention this somewhere in documentation :D).
I hope this answers your questions.
PS: Found and fixed another bug in the version. 1.0.9 coming tomorrow.
-
As for problem with "do"s and "don"s, can you please bit a little more specific. Can you please post names of the files in your project - this will allow me to reproduce the problem and fix it. What was the search pattern you used and what is the result you expected to see. Also, what version of SlickEdit you have?
It's such a basic problem that you couldn't miss it, so maybe it only happens on SE 13, or maybe it is somehow being affected by some other macro. I'll try to describe it more thoroughly:
SlickEdit 13.0.0 r17, on Vista.
Suppose the project has 3 files:
A.c
Ab.c
D.c
Steps:
1. Press the key bound to -open-project-file.
Result: the dialog opens and lists all files: A.c, Ab.c, D.c.
2. Type a letter that you expect will filter the list: in this example, try "a".
Result: the letter appears in the text box at the top, but the list is not filtered at all yet, it still lists all files: A.c, Ab.c, D.c (it should list only files that match "a", so it should only list A.c, Ab.c).
3. Type a second letter that you expect to further filter the list: in this example, try "b".
Result: now the list gets filtered per the letter you typed in step 2 (but not step 3): it lists A.c, Ab.c (it should list only files that match "ab", so it should only list Ab.c).
4. Press the Backspace key.
Result: now the list is filtered by both the characters from steps 2 and 3: it lists only Ab.c (it should list files that match "a", so it should list A.c, Ab.c).
-
@chrisant
Thanks a lot for thorough bug report!
This is the exact problem I fixed in 1.0.9. Here's the new version.
The problem is that tree control in SE refreshes itself before you make change to nodes and not after. So when you pressed "a" character in step 2, it kept showing all files. Then when you pressed "b" in step 3, the tree got redrawn before the macro started modifying tree contents, so it showed files matching "a" pattern.
To fix that, I added a call to _TreeRefresh() every time I make changes to the tree. This makes sure that tree shows most uptodate information.
-
I'm having some troubles with this macro and absolute paths. [SE v13 and Windows.] My project properties has files listed as such:
..\..\slickedit2008\sysconfig\vscpp.h
..\..\slickedit2008\sysconfig\vsparser\vscpp.h
\dev\smac\bin\b.bat
\dev\smac\bin\build.php
When I try to open vscpp.h, it works. When I try to open b.bat or build.php, it fails in opf_files.on_change() because of the strip_filename(name, "D") logic. This code:
if (reason == CHANGE_LEAF_ENTER) {
name = _TreeGetCaption( index );
say("name:'" name "'");
say("strip_filename( name, 'D' ):'" strip_filename( name, "D" ) "'");
// If after stripping path filename remains the same, we should append project directory
// to filename as the name is relative to project path. Otherwise we should use the name
// as is.
if (strip_filename( name, "D" ) == name) {
proj = _project_get_filename();
say("proj0:'" proj "'");
proj = strip_filename( proj, "N" );
say("proj1:'" proj "'");
name = proj :+ name;
say("name:'" name "'");
}
produces this result:
name:'/dev/smac/bin/b.bat'
strip_filename( name, 'D' ):'/dev/smac/bin/b.bat'
proj0:'c:\slm\slickedit2008_projects\SlickC\SlickC.vpj'
proj1:'c:\slm\slickedit2008_projects\SlickC\'
name:'c:\slm\slickedit2008_projects\SlickC\/dev/smac/bin/b.bat'
I'm not sure what the best way to fix this would be, but I'm guessing that maybe it should be checking for the leading '.' to find relative paths?
Thanks much,
-Mike
-
@mikesart
Thanks a lot for reporting this. I am sorry but it will take me some time to fix this problem because I don't have SE2008 at the moment - I used trial version to test the macro on SE2008, but this is now over. I'll think of a solution, but it will take some time.
-
I changed this line:
if (strip_filename( name, "D" ) == name) {
to this:
if(substr_(name, 1, 1) :== '.' ) {
*** Note I had to add the '_' after substr_ otherwise I keep getting "POST to /index.php not supported" when trying to preview or post this message. This occurs in code blocks as well.
And it seemed to work decently well. At least in my projects.
Couple of other things:
1. Periods are treated as regex match any char. So when trying to open "blah.h", I also got hits for "blah_hook.cpp". I added this line in opf_string_match() to fix this for me:
regex = stranslate( regex, "\\.", "." );
2. I also had similar problems with underscores in filenames. So I replaced this line:
regex = translate( regex, ' ', '_' );
with this:
regex = stranslate( regex, "\\_", "_" );
3. The biggest thing I ran into after all that was the macro only lists files in the current project, not workspace like project-load does. So, for instance, I typically have two projects in my workspace; one is the source code I'm working on and the other is the compiler header files and crt source. Right now opf() won't list any files in the non-default compiler project. I started to took a look at modifying opf() to use code similar to _GetWorkspaceFilesH(), but am a bit short on time at the moment so I'm back to using project-load for now.
These things are probably more specific to how I work though - so please don't worry about spending time adding these features to your macro for just me. I'll make these modifications when I get some more time.
Thanks much asandler,
-Mike
-
Re: escaping regex characters, a more general solution would be to call _escape_re_chars which will also catch all of the other regex characters that can lead to problems (such as []()^$ etc).
-
@mikesart: the substr_() instead of strip_filename() fix you suggested breaks the macro - after changing it this way, it fails to open files located in the root directory of the project.
It's evident - this if statement checks whether the file name as we know it consist of file-name only. I.e. it doesn't have prepended path to the file. If it's true, then macro prepends path to the project file to the filename, assuming that file in the same directory as project file. You can try something like this:
if ((strip_filename( name, "D" ) == name) || (substr_( name, 1, 1 ) :== ".")) {
This takes care of both worlds. Please see if it works for you and if so, I'll release a version with a fix.
I agree with 1. Periods should indeed be translated into periods. However, I want to do something different. I want the macro to filter out all header files when you type .c. I.e. today (even with your fix) when the pattern is "ma.c", it will filter out "main.c". I don't want it to do so. Instead I want it to filter out all header files (in addition to all files that do not match "ma"). See my point? What do you think about that?
I also agree with 2. I'll fix it in the next version of the macro. As for point 3, there may be a problem - it's quiet a change and I'll need some time to implement and test it.
Thanks a lot for your help.
-
@chrisant: Be aware that the Files TB uses a super-fast DLL function _FilterTreeControl() to do the filtering.
For large scale projects it makes a BIG difference in comparison with using the Slick-C macro code (which is still there but #ifdef'd). Maybe it's a good idea to send a feature request regarding an enhancement of this function.
I can do one better than sending a feature request. I've written a macro + DLL which provides a "file open" dialog that lists Project files or Workspace files (like the Files toolbar) or files from a specified directory (like the Open toolbar). It shows the actual file icons, and retrieves the icons on a background thread (so the editor remains responsive even if some icons take extra time to retrieve).
Unlike the Files toolbar, my dialog defaults to using a prefix match. It supports * and ? wildcards, so use "*foo" to match "foo" anywhere in the file name.
Also unlike the Files toolbar, the files list in my dialog is sorted only by filename, and the path is shown in parentheses after the filename and is colored in gray. So for example use "bar\*foo" to match "foo" anywhere in the file name for files in a path ending in "bar".
I'll post it in a separate thread in a week or so after adding a few more minor improvements. And I'll include full source code, too (even for the DLL).
A couple quick screen shots attached here for illustration.
-
Very promising chrisant - and good luck getting it done !
Do you plan to add any options (e.g. strict prefix match, CaSe sens. etc. ) just as variable or maybe even w/ GUI support ?
HS2
-
Yes, some of the minor improvements I've still to make are adding a few options.
-
@chrisant: Nice idea. It should be much faster comparing to slick-c only macro.
I urge you to use my original idea for the filtering specification. The problem with asterisks and question marks is that people don't use them when they think. Often, you only remember part of the file name and perhaps part of its location in the project. Use it to filter out irrelevant files.
I am now testing a version with more or less final version of the "language". It has three basic rules:
- Every plain word in the pattern considered to be part of the file-name.
I.e. pattern "aaa bbb" will match "aaa_bbb_ccc.c" and "bbb_ccc_aaa.h". - Once you type in period, everything from the period to the end of the word is an extension.
I.e. pattern "aaa bbb.c" will match "aaa_bbb_ccc.c", but will not match "bbb_ccc_aaa.h". - Every word that has a slash (or back-slash) character in it, considered to be part of the path name.
I.e. xxx/ matches all files sitting in the xxx directory in the project/workspace.
Also, I always consider word in the pattern to be only a part of the file-name/extension/path. So, .c will match all files with .cpp extension as well.
The filtering routine has three parts, first testing file-name, second testing extension (if specified) and third testing path (if specified). This ends up to be a very elegant routine.
So if you are looking for a some_dir/another_dir/main_cpp_file.cpp, you will have to type "main some/ .cpp" or ".cpp main some/" or "main.cpp some/". All of these will match the file.
-
@asandler: I also prefer your more 'fuzzy' filter spec. as used in 'opf'/'ols'. So I'm looking forward to chrisant's release including the sources and I hope I can make use of it for the 'ols' macro. Maybe it's a good idea to extend the DLL with an alternative tree filter function and re-post it...
@chrisant: I'm just curious: Do you filter and manipulate a tree control with your DLL function(s) ?
HS2
-
asandler: At some point I may make it accept multiple patterns separated by spaces (maybe even soon). But honestly I don't filter that way. I have about 25,000 files to filter through. I tend to use uniqueness to filter, rather than figuring out regular expressions or multiple sets of strings to use. I know exactly what file I want to open, and I just want to reduce the amount of typing to a few characters -- I don't want to use a filtering syntax, that takes too much thought (and I have 15+ years of neural pathways trained to use short unique phrases to filter the list). Nevertheless I may add support for something similar to how opf works at some point.
Also, my filter assumes prefix matching unless you prefix the text with a star. So just by typing normally I can match by prefix or sub string or use normal wildcards. A major design goal I had was to avoid some kind of special syntax, and just filter naturally.
hs2: Yes, the entire dialog is implemented in the DLL (but it gets the list of project/workspace files by calling back into Slick-C). In order to get good performance I needed to use a virtual listview, which was only possible in DLL code. Filtering 25,000+ files is instanteous on my 2GHz laptop. Also, the filtered list is just an array of backpointers to the unfiltered list, so it takes less processing to build the filtered list. The down side is that unless I resort to some hackery, it can only be a modal dialog (not a floating or docked toolbar). But that's fine for my purposes.
Actually ultimately I don't even want tabs, but I'm experimenting with that UI metaphor first since there seems to be such a pervasive distinction between project and workspace file lists in SlickEdit. As the UI evolves I'm really looking to reduce the modes (tabs), or perhaps to automatically deduce when to look directly in the file system, or perhaps even just merge in file system matches with workspace file list matches. I like the idea of merging the workspace file list with the file system file list (e.g. relative to the cwd or whatever path has been typed), as it fits nicely with my goal of just typing naturally and having the filtering quickly reduce to what I was looking for, without having to think about or select tabs, and without having to think about how to use a special filtering syntax. I don't know how that will turn out, but I'll certainly experiment with it.
-
Ok wow. There is a bug in the forums: if I try to include the word "s u b s t r i n g" in the message text then I get a 501 error. It took me a few weeks to finally figure out why sometimes I get 501 errors.
-
In order to get good performance I needed to use a virtual listview, which was only possible in DLL code
My GFileman toolbar has a multicolumn "virtual" listview using listboxes but unfortunately I'm not able to capture mouse wheel scroll events which is annoying, but it's only for open buffers, not workspace or project files so I don't need to scroll very often.
Graeme
-
My GFileman toolbar has a multicolumn "virtual" listview using listboxes but unfortunately I'm not able to capture mouse wheel scroll events which is annoying, but it's only for open buffers, not workspace or project files so I don't need to scroll very often.
Oh, thanks. I downloaded and reviewed the sources for GFileman, but I don't understand where it's using a virtual listbox (I see it calling _lbitem_add, for example, which never occurs in a virtual listbox). Can you point me at the code? Or maybe we mean different things by "virtual listbox"? I'm talking about where you set a listview or listbox (etc) to not store a list of items, and instead have it to call back into your own code whenever it needs to retrieve an item or draw an item, etc. How are you getting Slick-C to call you back for retrieving and drawing items? It would be useful to know how to do that in Slick-C code.
Here is a quick explanation of a "virtual listbox" lifted from some .NET documentation:
One of these is the LBS_NODATA style. As the name suggests, when a ListBox has the LBS_NODATA style, the control no longer stores any data for items, instead you simply tell it how many items should be displayed and it calls back whenever an item needs to be displayed using the DrawItem method. Of course, that means that the data must be held externally, and in a way that can be accessed based on the row number of the item to be displayed.
-
Ah, sorry. We sort of mean similar things I guess. I don't store all the data in the list-boxes. The only data that's stored in the list-boxes is what can be seen on the screen - otherwise I can't get the multi-column behaviour. I handle mouse clicks and selection explicitly and disallow scrolling.
Graeme