Add your own alternative version
Stats
296.4K views 3.7K downloads 150 bookmarked
Posted
6 Jan 2003
|
Comments and Discussions
|
|
This looks like a really useful tool, but I work in C++ and FORTRAN mixed language apps, so ....
Would it be possible to set the 'form' or 'forms' of the include statements as an option? THe way our includes are, we could have all sorts of extensions for our include files...
E.g...
C++/C
#include 'file.h'
#include <file>
FORTRAN
INCLUDE 'file.str'
INCLUDE 'file.prm'
INCLUDE 'file.cmn'
INCLUDE 'file.inc'
Obviously if this could be made to work, it would apply to any language.
Dan
|
|
|
|
|
open the application, slect the directory tab, slect the directory by clicking the ... button and select start button, include finder crashes
Regards
Sunil
|
|
|
|
|
Thanks for the bug notification, however, I can't reproduce it. Could you please tell me the callstack at the point of the crash?
Thank you,
Chris Richardson Terrain Software
|
|
|
|
|
The way to reproduce this seems to be to leave the File mask field blank. If you set-up a filter then it won't crash.
|
|
|
|
|
Hi Chris,
It dos not work on wondows NT..
When tried to run the exe it pops up following error message:
"The procedure entry point SHGetSpecia;FolderPathA could not be located in the dynamic link library SHELL32.dll"..
Please let me know what is the problem..
|
|
|
|
|
I've modified the program so it won't rely on that function. I will update the article probably tomorrow. Also, sorry it took so long to reply, but I was on vacation until today .
Chris Richardson Terrain Software
|
|
|
|
|
Many thanks for this nifty tool.
One of my projects exposed a bug. Variable "a_szCurrentPath" was left blank when testing include paths.
In CParser::FindFullPath()
*
*
*
if( !a_bFoundPath )
{
// Inserted code to set a_szCurentPath
CLexer * a_poLexerParent = c_oLexerStack[0];
_tcscpy( a_szCurrentPath, a_poLexerParent->GetName() );
a_pszSep = _tcsrchr( a_szCurrentPath, _T('\\') );
if( a_pszSep )
*(a_pszSep) = 0;
// Search for the file in the include directories.
for( int i = 0; i < c_oIncludeDirs.size(); ++i )
{
CTCharString & a_rsIncludeDir = c_oIncludeDirs[i];
|
|
|
|
|
Thanks for the kind comments . I've applied your bug fix to my code base, and will update the zip files sometime soon.
May I ask how you ran across this bug (just cause I'm too curious).
Thanks,
Chris Richardson
You can stash and you can seize
In dreams begin, responsibilities U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your - Rohit Sinha in the content-challenged thread
|
|
|
|
|
IncFinder was not finding bracketed include files that resided in any of the "/I" paths in the DSP file.
|
|
|
|
|
"The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.dll"
Windows NT 4.0 SP6 + IE5.00
|
|
|
|
|
This problem is due to corrupt installation of your IE. This error generally occurs when your system dont have IE 4.1 or greater. Do one thing uninstall your current IE version,download IE 5.5 or higher . While runnig IE setup file use IE6Setup.exe /C:"ie6wzd /e:IE4Shell_NTx86 /I:Y".
|
|
|
|
|
|
Thank you, I'm glad you like it
Chris Richardson
You can stash and you can seize
In dreams begin, responsibilities U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your - Rohit Sinha in the content-challenged thread
|
|
|
|
|
Your tool is very useful, however my main reason for needing it is to figure out why on earth MyFile.cpp is compiled when TotallyUnrelatedFile.h is changed.. It would be nice if the tree could automatically find me every path from MyFile.cpp down to TotallyUnrelatedFile.h, this would allow me to remove the offending include??
|
|
|
|
|
OK, so it already does! I wasn't expecting the find to be case sensitive. It would be nice to have this as an option though.
|
|
|
|
|
FindFullPath incorrectly handles two include files with the same name (but in different paths). In the code path for !p_bIsBracketed the relative part ( a_szExtra ) is completely ignored. So if you happen to have an include file with the same name in your local directory it incorrectly picks it up, instead of looking in the relative destination. I just added the two _tcscat lines.
<br />
if( !p_bIsBracketed )<br />
{<br />
...<br />
_tcscat( a_szPath, _T("\\") );<br />
<br />
_tcscat( a_szPath, a_szExtra );<br />
_tcscat( a_szPath, _T("\\") );<br />
<br />
_tcscat( a_szPath, a_szFileName );<br />
...<br />
}<br />
}<br />
Oliver Wahl
|
|
|
|
|
Simple minded as I am, I loaded a workspace, entered *.* as file spec and hit start.
When the app comes to the first .ico file which is included in the .dsp it locks up forever.
The problem is in the CLexer::Lex function where it reads the char and unget's it because its not a alpha, digit or underscore. So it runs in circles trying to CParser::Eat that byte.
[edit]... and hitting stop finally puts the nail in the coffin and kills the app totally...
The include finder thread has no means of terminating when it is stuck in a file.[/edit]
powerful binary resource reuse - another word for "no sources, you are stuck with a pain-in-the-a## COM component"
|
|
|
|
|
Hi,
Thanks for the information . I've fixed the problem, and updated the article and the downloads to reflect this fix, as well as a couple others. If you see any other bug reports, feel more than free to send them to me, and I'll keep the source updated with the fixes.
Andreas Saurwein wrote:
[edit]... and hitting stop finally puts the nail in the coffin and kills the app totally...
The include finder thread has no means of terminating when it is stuck in a file.[/edit]
I'm going to take a look at changing this. Even though I've fixed the current lockup, there may be more in the future, I would like to handle them better.
Thanks,
Chris Richardson
C/C++ Include Finder[^]
|
|
|
|
|
Working on an empty include file the open method fails to create a file mapping and returns an error which aborts parsing of the parent (should it ?). Here is my fixed version of CMMFStream::Open to check the file size first before creating a mapping. It now keeps on working after processing an empty include file.
<br />
ParseStatus CMMFStream::Open( const TCHAR * p_pszPath )<br />
{<br />
if( c_hFile != INVALID_HANDLE_VALUE )<br />
return PARSE_STATUS_FILE_ALREADY_OPEN;<br />
<br />
c_pcBuf = NULL;<br />
_tcscpy( c_szFileName, p_pszPath );<br />
<br />
// Open a handle to the file.<br />
c_hFile = CreateFile( p_pszPath,<br />
GENERIC_READ,<br />
0,<br />
NULL,<br />
OPEN_EXISTING,<br />
0,<br />
NULL );<br />
if( c_hFile == INVALID_HANDLE_VALUE )<br />
return PARSE_STATUS_FILE_OPEN_FAILED;<br />
<br />
c_ulBytesLeft = GetFileSize( c_hFile, NULL );<br />
<br />
if( c_ulBytesLeft > 0)<br />
{<br />
// Create the file mapping object.<br />
c_hMapping = CreateFileMapping( c_hFile,<br />
NULL,<br />
PAGE_READONLY,<br />
0,<br />
0,<br />
NULL );<br />
if( !c_hMapping )<br />
{<br />
CloseHandle( c_hFile );<br />
c_hFile = INVALID_HANDLE_VALUE;<br />
<br />
return PARSE_STATUS_FILE_OPEN_FAILED;<br />
}<br />
<br />
// Map the file into memory.<br />
c_pvBaseAddress = MapViewOfFile( c_hMapping,<br />
FILE_MAP_READ,<br />
0,<br />
0,<br />
0 );<br />
if( !c_pvBaseAddress )<br />
{<br />
Close();<br />
return PARSE_STATUS_FILE_OPEN_FAILED;<br />
}<br />
<br />
c_pcBuf = (TCHAR*)c_pvBaseAddress;<br />
}<br />
<br />
return PARSE_STATUS_OK;<br />
}<br />
Oliver Wahl
|
|
|
|
|
Hello,
I've updated the article and the downloads to include your two fixes, as well as a couple other fixes. Thanks a lot for the interest, as well as providing the patches to me.
Chris Richardson
C/C++ Include Finder[^]
|
|
|
|
|
I tried to start it on the larger system, it finished by error with such call stack.
Is error in my use?
CMMFStream::UngetC(char 10) line 157 + 6 bytes
CLexer::Lex(CToken * 0x00f1fcf4) line 101 + 23 bytes
CParser::Eat(ParseTokens TOKEN_IDENTIFIER) line 199 + 26 bytes
CParser::ParsePreprocessorStatement() line 611
CParser::ParseFile() line 324 + 8 bytes
CParser::ParseInternal(const char * 0x00f1f58c) line 284 + 8 bytes
CParser::ParsePreprocessorStatement() line 403 + 15 bytes
CParser::ParseFile() line 324 + 8 bytes
CParser::ParseInternal(const char * 0x0102df21) line 284 + 8 bytes
CParser::Parse(const char * 0x0102df21, std::list<CParsedFile *,std::allocator<CParsedFile *> > * 0x00374d40, void * 0x00000714) line 216
CIncludeFinder::ThreadLoop() line 99
CIncludeFinder::ThreadProcedure(void * 0x00374d68) line 65 + 13 bytes
KERNEL32! 77e7d33b()
My brain works on 100 Hz CPU clock
|
|
|
|
|
Sorry to hear that it's crashing, and no, it's not your fault (it's a bug in my program). It would be a great help to me if you could send the line of code it's processing when it fails (the line of code in your cpp file). Here's how you can get the file name and line number, to determine where the parser currently is:
1. CMMFStream has a member c_szFileName , which is the name of the file that's currently being processed.
2. Double click on the callstack entry that says "CLexer::Lex(CToken * 0x00f1fcf4) line 101 + 23 bytes", then take a look at the c_ulLine member of CLexer. This is the current line number in the file that's being processed.
Now, you can open the source file and go to the line that was being processed. If you could send me this line, or a mocked up line which has the same form, I'll try to locate the problem. If you can't send it, that's alright, I'll try and have a look anyways (but don't know how far I'll be able to get).
Thanks,
Chris Richardson
C/C++ Include Finder[^]
|
|
|
|
|
Hey, I just wanted to let you know I found the bug that was causing your crash (well, I found one that lead me to the same callstack). Thanks for the email today, it helped me a lot. I've updated the article and the downloads so they will reflect this fix (as well as a couple others).
Chris Richardson
C/C++ Include Finder[^]
|
|
|
|
|
Thanks, now it seams to work.
1) Each program has at least one error
2) When removed, the rule 1) is still valid
It is logical nonsens, but praxis confirms it!
|
|
|
|
|
After a condiserable amount of swearing I finally got your excellent tool working. It is, apparently, strictly forbidden to enter "*.h" among the file masks. If you do, the result is: nothing. Maybe a little warning about this would be appropriate? Or maybe it wasn't intended for stupid morons like me that fail to realise that all the header files will be included automatically...
Anyway, now that it works, it's fabulous!!!
This is not a signature.
|
|
|
|
|
|
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
|