Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Find Symbol dialog feature request

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
MrDoomMaster Posted - Apr 11 2008 : 11:55:32 AM
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.
11   L A T E S T    R E P L I E S    (Newest First)
support Posted - Sep 13 2008 : 01:01:16 AM
case=12853 is implemented in build 1649
feline Posted - Apr 23 2008 : 5:17:53 PM
We are considering doing something like this:

case=12853
phillipfoose Posted - Apr 23 2008 : 11:16:23 AM
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.
feline Posted - Apr 18 2008 : 10:59:50 AM
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
mwb1100 Posted - Apr 18 2008 : 02:39:34 AM
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);
}

feline Posted - Apr 16 2008 : 2:16:21 PM
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.
mwb1100 Posted - Apr 14 2008 : 8:44:57 PM
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.
MrDoomMaster Posted - Apr 14 2008 : 2:37:24 PM
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 :)
feline Posted - Apr 14 2008 : 1:36:24 PM
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.
MrDoomMaster Posted - Apr 11 2008 : 2:27:59 PM
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.
feline Posted - Apr 11 2008 : 1:50:29 PM
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.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000