RE: Re: need help with visual studio

> > > While the app is running, right click the titlebar of the 
> > > console/output window and you will find some options.
> > > You may have autohide turned on. You can turn on
> > > dockable if it isn't already dockable, then drag it to any
> > > edge of the VS.NET window and it will stick there. Let
> > > me know if that doesn't do the trick.
> 
> I couldn't find either autohide or dockable in any option 
> menu for the console window in my XP.

Oh man, was I confused last night or what! I was thinking of Visual Studio's
Output window, but you were talking about the console window in Windows. (My
phrase "console/output window" was a clue about my confusion. <g>) Sorry
about the mixup.

I don't think there is any way to make the console window stay open. When an
app exits, Windows closes all of its windows.

But there are other options. You mention wanting to break on assertion
failures. If these asserts are in your own code, you can make this happen
automatically. Here is some code (based on tested C++ code, may need a tweak
or two to work with Antique C). I made the lines short to avoid word wrap in
the email.

// In a .h file:

#ifdef WIN32
    #define debugBreak()  { _asm int 3 }
#else
    // define debugBreak for other OSes
#endif

#ifdef _DEBUG

    extern void trace( const char* pszFormat, ... );

    extern void assertTrace(
        const char* pszMessage,
        const char* pszFile,
        int nLine );

    #define assert( expr )  \
    {  \
        if( !(expr) )  \
        {  \
            assertTrace(  #expr, __FILE__, __LINE__ );  \
            debugBreak();  \
        }  \
    }
#else

    #define trace  1 ? (void)0 :
    #define assert  1 ? (void)0 :

#endif

// In a .cpp file:

#ifdef _DEBUG

// It's up to you to avoid buffer overrun here, but this
// is just in your own debugging calls anyway
void traceV( const char* pszFormat, va_list args )
{
    char szMessage[5000];
    vsprintf( szMessage, pszFormat, args );

#ifdef WIN32
    OutputDebugString( szMsg );
#else
    // Trace for other OSes here
#endif
}

void trace( const char* pszFormat, ... )
{
    va_list args;
    va_start( args, pszFormat );

    traceV( pszFormat, args );

    va_end( args );
}

void assertTrace(
    const char* pszMessage, const char* pszFile, int nLine )
{
    trace( "Assert failed: %s, file %s line %d\n",
        pszMessage, pszFile, nLine );
}

#endif

So, now you have a trace() function that accepts a format string and other
printf-style arguments, e.g.

    trace( "string=%s, number=%d\n", pszFoo, nFoo );

traceV() is broken out as a separate function so it can be called from other
functions that do their own va_list processing. This function traces to
VS.NET's Output window, not to a console window, so the output survives app
shutdown.

And, you have an assert(value) function that calls this trace and then
breaks into the debugger at the source line that hit the assert.

trace() and assert() compile down to nothing if _DEBUG is not defined, so
they won't affect release builds at all.

The code should be portable except for the #ifdef WIN32 parts. Let me know
if it doesn't work or if I left anything out.

> > By the way, do you have a problem with the mouse
> > not working in console windows when attached to
> > Visual Studio?  I have to right-click on the title bar
> > and do edit/select-all/enter to copy from the window.
> 
> Ignore this question.  I found the setting for this in my 
> search for the options above.  It turns out this option is 
> apparently off by default in XP, which is new to me.  I'm 
> used to NT and 2000.

I think Quick Edit mode was off by default in NT/2000 as well, but you
probably turned it on so long ago in the older OSes that you don't remember
changing it. That's what happened with me. :-)

Since we're talking about console windows, I find it very handy to go into
the Properties and change a couple of the other settings as well. In the
Layout tab, I make the window size bigger and the screen buffer size *much*
bigger--I set the screen buffer height to the max of 9999. In the Colors
tab, I set the screen text and background to black on white, to match all of
my editing windows. I find it hard on the eyes to switch back and forth
between black-on-white and white-on-black windows all the time. Much more
comfortable when they match.

-Mike