Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Find Symbol dialog feature request
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 11 2008 :  11:55:32 AM  Show Profile  Reply with Quote
Hi,

Would it be possible to add a column to the Find Symbol dialog named "File"? It would show the file that the symbol is located in. Sometimes I have ambiguous symbols, some of which are located in system header files and others are located in my project's source files. It would be nice to just be able to see the file anyway, IMHO.

This should be an easy feature to add, so if you could get it into 1632 beta I would appreciate it! Thanks.

feline
Whole Tomato Software

United Kingdom
18943 Posts

Posted - Apr 11 2008 :  1:50:29 PM  Show Profile  Reply with Quote
Are you aware that if you hover the mouse over the symbol column in the Find Symbol dialog that the path and line number are shown in a tooltip?

Not quite the same but this should help.

I am slightly concerned about fitting in the file path (you need the full path to handle duplicate file names) as another column, since the text in both the symbol and definition columns already tends to get rather long.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 11 2008 :  2:27:59 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

Are you aware that if you hover the mouse over the symbol column in the Find Symbol dialog that the path and line number are shown in a tooltip?

Not quite the same but this should help.

I am slightly concerned about fitting in the file path (you need the full path to handle duplicate file names) as another column, since the text in both the symbol and definition columns already tends to get rather long.



Yeah, using a full path wouldn't work. I was thinking of some cute algorithm you guys could implement to maybe show the file plus the containing directory, for example:

I have a file in:
C:\\myproject\\source\\files\\main.h

The column would display:
files\\main.h

Again, this might not work since you can have similar folder paths up to a point. You could of course also do this:

C:\\myproject\\...\\main.h

Or something similar. I didn't know that you could hover and get that information, so that might work out for me. I understand your concerns with the extra column, as not everyone has a large monitor like me.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18943 Posts

Posted - Apr 14 2008 :  1:36:24 PM  Show Profile  Reply with Quote
One problem with trimming the path is where do we trim it? Any simple and consistent method of trimming / shrinking the path is going to run into "problems", since it will trim the important bit for some common directory structure layout.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 14 2008 :  2:37:24 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

One problem with trimming the path is where do we trim it? Any simple and consistent method of trimming / shrinking the path is going to run into "problems", since it will trim the important bit for some common directory structure layout.



Trim based on the width of the column. You could follow a consistent pattern where you try to display an equal amount of depth on either side of the '...' symbol.

Again, this isn't worth it probably. The hovering will work just fine :)
Go to Top of Page

mwb1100
Ketchup Master

82 Posts

Posted - Apr 14 2008 :  8:44:57 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

One problem with trimming the path is where do we trim it? Any simple and consistent method of trimming / shrinking the path is going to run into "problems", since it will trim the important bit for some common directory structure layout.



Use the Win32 API PathCompactPath() or PathCompactPathEx(). That way any problems with the resulting string can be blamed on Microsoft!

Also, since the column is resizeable if the user needs to see more of the path the capability is there with some swipes of the mouse.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18943 Posts

Posted - Apr 16 2008 :  2:16:21 PM  Show Profile  Reply with Quote
There was a recent thread about path compacting that listed one of these API's. I remember posting the examples from Microsoft's documentation on the function to the thread, since the examples showed the very problem the poster was trying to avoid by using them.

zen is the art of being at one with the two'ness
Go to Top of Page

mwb1100
Ketchup Master

82 Posts

Posted - Apr 18 2008 :  02:39:34 AM  Show Profile  Reply with Quote
Here are a couple possible ways to deal with the problems in this thread and the other one you referred to:

1) replace common long paths (such as the default VS project location) with something like the VS macro names (like $(ProjectDir) or something).

2) Here's a sample bit of code that has an 'extended' version of PathCompactPathEx() that lets you specify how many directories closest to the filename can be protected from being elided. It's quick-n-dirty and not pretty, but it should work in VC6 or later and should work with multi-byte or Unicode builds.


#include <windows.h>
#include <iostream.h>
#include "tchar.h"
#include "Shlwapi.h"


BOOL PathCompactPathEx2( LPTSTR pszOut, LPCTSTR pszSrc, UINT cchMax, DWORD cProtectDirs);


void main( void )
{
    LPCTSTR pFilename = TEXT( "C:\\\\Documents and Settings\\\\MyName\\\\My Documents\\\\Visual Studio Projects\\\\SolutionName\\\\ProjectName\\\\somefile.cpp"); 
    
    TCHAR outString[MAX_PATH];

    // Variable to get the return from "PathCompactPathEx".
    int retval;

    cout << "The un-truncated path is               " << pFilename << endl;

    cout << "Protecting 2 path components:" << endl;

    retval = PathCompactPathEx2( outString, pFilename, 100, 2);
    cout << "The truncated path at 100 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 80, 2);
    cout << "The truncated path at  80 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 60, 2);
    cout << "The truncated path at  60 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 40, 2);
    cout << "The truncated path at  40 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 20, 2);
    cout << "The truncated path at  20 chars is :   " << outString << endl;
    
    cout << "Protecting 1 path components:" << endl;

    retval = PathCompactPathEx2( outString, pFilename, 100, 1);
    cout << "The truncated path at 100 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 80, 1);
    cout << "The truncated path at  80 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 60, 1);
    cout << "The truncated path at  60 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 40, 1);
    cout << "The truncated path at  40 chars is :   " << outString << endl;

    retval = PathCompactPathEx2( outString, pFilename, 20, 1);
    cout << "The truncated path at  20 chars is :   " << outString << endl;
    
}


BOOL PathCompactPathEx2( LPTSTR pszOut, LPCTSTR pszSrc, UINT cchMax, DWORD cProtectDirs)
{
    if (0 == cProtectDirs) {
        return( PathCompactPathEx( pszOut, pszSrc, cchMax, 0));
    }
    
    size_t pathSeparators = 0;
    
    {
        for (LPCTSTR pSrc = pszSrc; *pSrc; pSrc = CharNext( pSrc)) {
            TCHAR ch = *pSrc;
            
            if ((ch == TEXT('\\\\')) || (ch == TEXT('/'))) {
                ++pathSeparators;
            } 
        }
    }
    
    if (cProtectDirs >= pathSeparators) {
        // not enough path components in the original string to do anything special
        return( PathCompactPathEx( pszOut, pszSrc, cchMax, 0));
    }
    
    pathSeparators = pathSeparators - cProtectDirs;
    
    TCHAR tempName[MAX_PATH];
    
    LPTSTR  pNew = tempName;
    LPCTSTR pSrc = pszSrc;
    
    for (;;) {
        TCHAR ch = *pSrc;
        
        if ((ch == TEXT('\\\\')) || (ch == TEXT('/'))) {
            if (0 == pathSeparators) {
                break;
            }
            --pathSeparators;
        }
        
        // odd way to copy next char from src to dst that deals with multi-byte
        LPCTSTR pNext = CharNext( pSrc);
        while (pSrc != pNext) {
            *pNew++ = *pSrc++;
        } 
    }
    
    *pNew = TEXT( '\\0');
    
    size_t excludedChars = _tcslen( pSrc);
    
    if ((excludedChars >= cchMax) || ((cchMax - excludedChars) <= 8)) {
        // not enough space for the protected portion of the path
        // just let the default implementation do its work
        return( PathCompactPathEx( pszOut, pszSrc, cchMax, 0));
    }
    
    // Pass on the call to Microsoft's implementation, with the 'protected' 
    // part of the path striped off
    BOOL result = PathCompactPathEx( pszOut, tempName, cchMax - excludedChars, 0);
    
    if (!result) {
        // our funky version of PathCompactPathEx() failed - call it using the 
        // unmodified parameters in case someone's going to depend on some odd 
        // side effect that I'm unaware of
        return( PathCompactPathEx( pszOut, pszSrc, cchMax, 0));
    }
    
    // put the protected part of that path back in place inthe output buffer
    _tcscat( pszOut, pSrc);
    
    return( result);
}

Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18943 Posts

Posted - Apr 18 2008 :  10:59:50 AM  Show Profile  Reply with Quote
These ideas make a lot of sense mwb1100, thank you Normally I try to avoid the idea of adding options to VA, but we would need one to use this path compacting code, and it seems reasonable.

I have put in a feature request to see what our developers make of this:

case=16131

I would quite like to see a "good" solution for this implemented myself

zen is the art of being at one with the two'ness
Go to Top of Page

phillipfoose
Junior Member

USA
23 Posts

Posted - Apr 23 2008 :  11:16:23 AM  Show Profile  Reply with Quote
quote:
Originally posted by feline

These ideas make a lot of sense mwb1100, thank you Normally I try to avoid the idea of adding options to VA, but we would need one to use this path compacting code, and it seems reasonable.

I have put in a feature request to see what our developers make of this:

case=16131

I would quite like to see a "good" solution for this implemented myself



I have another feature request for this dialog -

If you've found the symbol you are looking for, if you hit shift-enter or control-enter, it would insert the highlighted symbol name into the code at the current insertion point.

I find myself using the find symbol as a lookup for a symbol name i'm not sure of, and currently, I find the name, then close the dialog then have to type or auto complete it.

Not a big deal but should be fairly easy to implement and useful.

Thanks for all the hard work.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18943 Posts

Posted - Apr 23 2008 :  5:17:53 PM  Show Profile  Reply with Quote
We are considering doing something like this:

case=12853

zen is the art of being at one with the two'ness
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Sep 13 2008 :  01:01:16 AM  Show Profile  Reply with Quote
case=12853 is implemented in build 1649
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000