Board index » cppbuilder » Massive Problem Solved - Thank you. Not yelling . .

2003-07-29 04:20:25 PM
cppbuilder90
Thanks to all for the input on this.
Couple of points:
weeks on this. In fact in one of the postings I asked whether
editing imagehlp.h exactly as recommended '::Long64' was the way
forward and a Team B response questioned the wisdom of monkeying
with system headers. So I thought the solution must lie elsewhere. That's when my troubles began.
Thanks again for all replies.
Mark D
 

Mark D wrote:
Diener's advice to make sure that imagehlp.h doesn't use an
ambiguous type.
--
Jonathan Arnold C/C++/CBuilder Keen Advice:
www.keen.com/categories/categorylist_expand.asp
Comprehensive C++Builder link site:
www.buddydog.org/C++Builder/c++builder.html
 

Jonathan Arnold wrote:
designation. That is to what the OP was referring, and I agree that one
should not change a system header if it at all can be avoided. Chris U. had
the right answer. It should not necessary to use the define I suggested if
one prefaces all uses of LONG64 with either ::LONG64 for the Windows version
or System::LONG64 for the VCL version.
 

{smallsort}

Edward Diener wrote:
file, he is getting an error in <imagehlp.h>for the ambiguous error.
So he needs to somehow tell imagehlp.h to not{*word*222}up. It isn't his
code. And I thought that's what your suggestion did. Dunno myself!
--
Jonathan Arnold C/C++/CBuilder Keen Advice:
www.keen.com/categories/categorylist_expand.asp
Comprehensive C++Builder link site:
www.buddydog.org/C++Builder/c++builder.html
 

Jonathan Arnold wrote:
an error if he isn't trying to actually use LONG64 unless the compiler is
seeing two different declarations of the same variable or type.
In reality the VCL would have been much better designed if the IDE honored
namespaces in C++ but as I and others have demonstrated, it ignores
namespaces when generating code C++ Builder code and VCL C++ namespaces have
even been dropped from BCB6 VCL header files entirely. How's that for a
backward step in program design !
 

Ed Diener writes:
slightly left me behind, I can report a moderate success.
I say moderate because the fix of making LONG64 ::LONG64
works on Windows 2000. On XP home, the call to
SearchTreeForFile (with the tweak in imagehlp.h) produces this
error message:
Access violation at address 6D51BC26 in module DBGHELP.DLL.
Write of address 4100464E.
Which is a bit of a pain because when I take this application
to market in July 2023, there may be a few customers around
still running XP.
Is there possibly a connection between this AV and the edit
to imagehlp.h?
I _need_ this app to search all fixed drives and all subfolders for a particular file on win2k and xp systems. If I can't get past this, is there another way apart from SearchTreeForFile?
The life so short, the craft so long to learn.
Thanks.
Mark
 

"Mark D" < XXXX@XXXXX.COM >writes:
sounds like you edited a system header. That's probably NOT a good
idea, because it's not a good idea getting into the business of
maintaining custom changes to other people's headers. Every time you
re-install, for example, you don't want to have to remember to apply
such changes. (Or if you have someone else compile for you, it's
hard to convince anyone to make header changes.)
there is a relationship or not.
FindFirst and FindNext (and FindClose).
I'm not sure how that compares to the other solution you're trying to
use.
--
Chris(TeamB);