none
Notebook window problems RRS feed

  • Question

  • Here's a weird problem.  My program makes a window with a solid model in it.  You can rotate, pan, and zoom.  If I zoom with the mouse button on my desktop, all is well.

    When I put a copy of the release exe on my notebook, the mousewheel zoom blanks the screen after the second update.  If I put the debug exe there, it works perfectly.

    Why would the release exe not work when the debug exe does?  This makes no sense to me.

    Wednesday, August 3, 2016 6:18 PM

Answers

  • These suggestions do not address the question of why the release version works on a desktop PC but not on a notebook.  Same code.  Different result.

    I'm wondering if there is a problem with the graphics driver in the NB.  The program uses OpenGL coding, which has to be supported by that driver.  A customer has had the same problem on his notebook, so it's not just something on mine.

    If I overflow an array or try to use an uninitialized variable, the debugger does a good job of catching the error.  But that is not happening.

    I'm sure that everyone in the community regrets that our psychic debugging abilities are not sufficient to quickly solve this problem.

    If your customer's notebook uses the same graphics driver as yours then perhaps your intuition is on the right track and this matter should be taken up with the publisher of the driver software.

    • Marked as answer by DonDilworth Thursday, August 4, 2016 3:10 PM
    Thursday, August 4, 2016 2:52 PM

All replies

  • You haven't given much info here but normally when you see a difference between debug and release it is due to the way the compiler handles variables, giving them default zero or NULL value(s), while in release they are essentially random. Look for uninitialized variables.
    Wednesday, August 3, 2016 7:10 PM
  • Good suggestion.  I found two uninitialized variables -- but they weren't being used.  I deleted them; same problem.

    So I added some lines that would print diagnostics in a text window.  The problem went away!  Here are the lines:

    // The absurd stuff below prevents the notebook display from blanking on mousewheel. Go figure.
        glGetFloatv( GL_MODELVIEW_MATRIX, m_matrix );
        CString text = "";;
        const char* name;
    //    text.Format("%f %f %f %f %f %f \r\n\n ",m_worldx,m_worldy,xmove,ymove,xdrag,ydrag);
        name = (LPCTSTR) text;
        writeTo->AddTextString( name );
    // End absurd stuff

    If I uncomment the Format line, it prints some numbers.  If I delete the name = and writeTo lines (which should have no bearing on the problem) the problem comes back!

    It looks like something is getting clobbered, and the extra code moves things around in memory.  Did I say weird?

    Wednesday, August 3, 2016 8:56 PM
  • Another difference in debug vs. release is that I believe there is some extra padding for array variables in debug that is not present in release. Check for array bound overwrites.
    Wednesday, August 3, 2016 9:26 PM
  • These suggestions do not address the question of why the release version works on a desktop PC but not on a notebook.  Same code.  Different result.

    I'm wondering if there is a problem with the graphics driver in the NB.  The program uses OpenGL coding, which has to be supported by that driver.  A customer has had the same problem on his notebook, so it's not just something on mine.

    If I overflow an array or try to use an uninitialized variable, the debugger does a good job of catching the error.  But that is not happening.

    Thursday, August 4, 2016 11:59 AM
  • These suggestions do not address the question of why the release version works on a desktop PC but not on a notebook.  Same code.  Different result.

    I'm wondering if there is a problem with the graphics driver in the NB.  The program uses OpenGL coding, which has to be supported by that driver.  A customer has had the same problem on his notebook, so it's not just something on mine.

    If I overflow an array or try to use an uninitialized variable, the debugger does a good job of catching the error.  But that is not happening.

    I'm sure that everyone in the community regrets that our psychic debugging abilities are not sufficient to quickly solve this problem.

    If your customer's notebook uses the same graphics driver as yours then perhaps your intuition is on the right track and this matter should be taken up with the publisher of the driver software.

    • Marked as answer by DonDilworth Thursday, August 4, 2016 3:10 PM
    Thursday, August 4, 2016 2:52 PM