Hi John,

Do you mean using the NoStepInto in AUTOEXP.DAT of  VC6?

If so, it may be a good resolution to your problem, however in VS.NET
2003(VC7.1), this function is moved into the registry underneath
HKCU\Software\Microsoft\VisualStudio\7.1\NativeDE\StepOver, for the detail
information about NoStepInto usage, please refer to the following links:
How to Not Step Into Functions using the Visual C++ Debugger
http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx

NoStepInto
http://www.codeguru.com/forum/showthread.php?t=292148

Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

--------------------

Hi John,

Does the NoStepInfo work for you?
If you have any more concerns on it, please feel free to post here.

Good Luck!

Best regards,

Gary Chang
Microsoft Online Partner Support

--------------------

Hi John,

The info is in this blog:
http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx

At your convenience, I posted the content here:

How to Not Step Into Functions using the Visual C++ Debugger
Disclaimer: This is not a documented or supported feature. That means it
was not tested, and might not work, and if it doesnt please dont call
Microsoft Support and complain. If it does work, then hoorah.



Introduction

Ever stepped into a function you didn??t want to? Like an ATL or MFC
CString constructor for example? Or a conversion operator you are really
not interested in? Well there is a way to tell the Visual Studio debugger
to never, ever step into a particular function. This is not a documented
option, but the information is available in newgroups, but the changes from
6.0 to 7.0 have caused a great deal of confusion. Here is the real story
for 7.0 (and 7.1).

Visual C++ 6

Visual C++ 6 users should run over to
http://www.codeguru.com/debug/autoexp.shtml to get the scoop. Life was
simple in VC6, but due to the fact that the ReadPrivateProfile API was used
to read the autoexp.dat file, there were some limitations on what could and
could not go in the file, especially equals signs. For this and other
reasons (eg non-Power users cannot write to autoexp.dat on an NTFS drive)
the information was moved to the registry for 7.0.



Visual Studio 7.0/7.1

The new list lives in the registry underneath
HKCU\Software\Microsoft\VisualStudio\7.0\NativeDE\StepOver (use 7.1 if you
are using Visual Studio 2003). The two last keys will not exist by default.
Underneath this you need to place a list of string values of decimal
numbers, paired with regular expressions. Figure 1 shows an example of this
from my VS 2003 machine. Using a screenshot is clearer than showing the
contents of a .reg file as .reg files need extra escape characters which
renders them much more meaningless. (I will show the matching .reg file
later). Due to an ??oversight?? (translation: bug) the items are evaluated
in descending numeric order e.g. the ??20?? rule will match before the ??10?
? rule. If you look at the example you can see that I have one rule, and
that is any function name that starts with ??ATL::?? will not be stepped
into.



The registry really contains ??ATL\:\:.*=nostepinto?? : lets dig into that
a bit more. Function names are specified using regular expression syntax,
the same as the rest of Visual Studio. In regex you need to escape colon
characters, hence the two ??\:?? sequences. The ??.*?? is regex for ??zero
or more of any character?? ie a general wildcard. The equals sign marks the
end of the function name, and ??nostepinto?? means functions matching this
patter will not be stepped into. The only other option for the
right-hand-side is ??stepinto?? which performs the exact opposite function:
it tells the debugger you want to step into these functions no matter what
other entries (that follow this one) say.

Having decoded the screenshot, here is the .reg file that was made when I
exported it. Note it is more complicated due to the escaping rules for .reg
files.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\NativeDE\StepOver]
"20"="ATL\\:\\:.*=nostepinto"



Advanced Features

The debugger supports additional escapes over and above the normal Visual
Studio regular expression syntax, but note that even I have never tried
these so YMMV. I got this list from comments in the source. Well I'm sure
you know that such things cannot always be trusted 100%, but here they are
anyway:

\cid      A C/C++ identifier

\funct   A C/C++ function name

\scope  A set of class/namespace specifiers for a function (e.g.
ATL::CFoo::CBar::)

\anything         any string

\oper    A C/C++ operator



Additional Examples

These examples are shown exactly how you would enter them via RegEdit, not
in the more cumbersome .reg format. The numbers are arbitrary, but in the
multi-line examples their relative values are important to get the right
ordering.

Don??t step into members of CString[AWT] etc:

1          \scope:CString.*\:\:.*=NoStepInto

Don??t step into overloaded operators:

10        \scope:operator\oper:=NoStepInto

Don??t step into ATL:: except for CComBSTRs non-operator members:

20        ATL\:\:CComBSTR::\funct:=StepInto

10        ATL\:\:.*=NoStepInto

Don??t step into templated things, unless they are merely templated
functions in a non-templated class:

20        \scope:\funct:=StepInto

10        .*[\<\>].NoStepInto



Notes

This is not a documented feature. Well obviously you are reading this ?
?documentation?? right here, but what I mean is that is not guaranteed to
work as it was never officially tested, not is it supported by Microsoft.
Its existence in future versions or update to current versions is not
guaranteed.
The registry is scanned when you Launch a debuggee via F5. It is not
scanned when you Attach to a process (a classic example of a feature that
was never properly tested).
It works only for the native C++ debugger. Managed languages can use the
DebuggerHiddenAttribute to achieve similar control but at the source level.
When choosing your regular expressions, you should check (via the
disassembly window) what the real names of the functions are. The real
names are often more complex then you might imagine, due to the use of
#define, namespaces, and templates. For example a simple CString
constructor with a char * argument in an MFC application is in fact called
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >

I hope that helps.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ?C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

When you attach to a process, you have the option of not debugging native
code.  Uncheck this option one time, and it should save this for when you run
with "Start Debug"

Amit