Making the Visual C++ 6.0 debugger not 'step in'

When debugging your code, it is likely that at some point you have accidently stepped in 'too far'. Whether it was into the constructor for CString or even just a piece of code that you've already debugged and *know* works, it's a pain to have to keep switching back and forth between doing 'step in' and 'step over'.

Thankfully, the debugger gurus at Microsoft seem to have seen this problem, too. As a quick warning, this feature is not documented and was just 'mentioned' by Andy Pennell in his presentation entitled 'Power Debugging with Visual C++ 6.0', given at the Boston '99 Visual C++ Developer's Conference. It also only works in Visual C++ 6.0.

Open up your autoexp.dat file -- in Common\MSDev98\Bin -- and add a new section named ExecutionControl to the end of the file and then add lines of the form: function=NoStepInto


[ExecutionControl]
CString::CString==NoStepInto
CString:::operator==NoStepInto

These three lines will cause the debugger not to step into the CString contructor or assignment operator. As is standard for any modifications to this file, you have to shut down and reload Visual C++ for this to take effect.

Date Last Updated: April 24, 1999


Comments

  • Attention: only one =, not two == before 'NoStepInto'

    Posted by icebear on 01/30/2009 02:37pm

    As shown in the other comments be aware not to use two == as described in the basic article.

    Reply
  • Can't manage to set NoStepInto for std::vector template class

    Posted by Legacy on 11/10/2000 12:00am

    Originally posted by: Maarten van Casteren

    I've tried to use the NoStepInto feature to prevent the debugger from stepping into the STL vector::operator[] function, which it does all the time if you use STL a lot.

    I tried (one at the time, of course):

    [ExecutionControl]
    std::*=NoStepInto
    std::vector::operator[]=NoStepInto
    std::vector<*>::operator[]=NoStepInto
    _STLD::vector<*>::operator[]=NoStepInto
    _STLD::vector<Layer*,_STLD::allocator<Layer*> >::operator[]=NoStepInto

    The first line being recommended by one of the other comments and the last line being what the call stack window displays. None of them works.

    Would somebody know how to do this?

    Thanks,

    Maarten.

    Reply
  • More capabilities

    Posted by Legacy on 08/29/2000 12:00am

    Originally posted by: Dejan Seatovic

    You can also use namespaces:

    ATL::*=NoStepInto
    std::*=NoStepInto

    coomplete class

    CString::*=NoStepInto

    Reply
  • Great! This was exactly what I've missed since years...

    Posted by Legacy on 08/20/1999 12:00am

    Originally posted by: Christoph Weber

    ... and of course was as usually nowhere documented by Microsoft...

    Reply
  • Templates?

    Posted by Legacy on 05/03/1999 12:00am

    Originally posted by: Nenad Caklovic

    Does anybody know the format for template classes and template functions?

    Reply
  • More samples

    Posted by Legacy on 04/27/1999 12:00am

    Originally posted by: Simon Capewell

    operator new=NoStepInto

    ; MFC
    CObject::operator new=NoStepInto
    CString::*=NoStepInto
    CSize::*=NoStepInto
    CPoint::*=NoStepInto
    CRect::*=NoStepInto

    Reply
  • CString:::operator==NoStepInto too many colons?

    Posted by Legacy on 04/26/1999 12:00am

    Originally posted by: Roger Onslow

    I am assuming that

    CString:::operator==NoStepInto

    should really be

    CString::operator==NoStepInto

    Is this correct?

    Roger

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • On-demand Event Event Date: October 29, 2014 It's well understood how critical version control is for code. However, its importance to DevOps isn't always recognized. The 2014 DevOps Survey of Practice shows that one of the key predictors of DevOps success is putting all production environment artifacts into version control. In this webcast, Gene Kim discusses these survey findings and shares woeful tales of artifact management gone wrong! Gene also shares examples of how high-performing DevOps …

Most Popular Programming Stories

More for Developers

RSS Feeds