[RESOLVED] MFC C++ multiple OnSetActive() calls happening at once - Page 2
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19

Thread: [RESOLVED] MFC C++ multiple OnSetActive() calls happening at once

  1. #16
    Join Date
    May 2013
    Location
    West Warwick, RI
    Posts
    8

    Re: MFC C++ multiple OnSetActive() calls happening at once

    Quote Originally Posted by 2kaud View Post
    I get very suspicious of problems that happen in release and don't in debug and when the problem changes or seems to go away when unrelated code is changed. This has the smell of a memory corruption issue.
    Normally I would agree with you, but I believe I have simplified the case enough to rule that out. I think it has more to do with how the messages are being triggered, if I run this in debug, I think the focus/message handling queue might end up looking differently, since the whole program is suspended while i'm stepping.

  2. #17
    Join Date
    May 2013
    Location
    West Warwick, RI
    Posts
    8

    Re: MFC C++ multiple OnSetActive() calls happening at once

    Quote Originally Posted by Arjay View Post
    AfxMessageBox calls do take focus, so when they are dismissed the previous window will regain focus. It is puzzling about the order of when the set active messages occur, but keep in mind that you are sleeping the ui thread for a long period of time and your original code had an AfxMessageBox immediately coming out of the sleep. When you block the main thread, all sorts of messages get queued or ignored or their priorities get changed - some messages get processed before others, so it becomes very difficult to determine what exactly is going on (and there are additional checks in debug mode that don't happen in release, so that complicates things as well).

    So the bottom line here is to not block the main thread for any extended period. You can pump messages in the middle of your operation code, or use a worker thread.

    Last comment, in terms of using TRACE, keep in mind that if you are debugging inside the VS IDE, the trace statements will show up in the output window. If you are running the debug version of your app outside the debug window, the trace statements will show up in a tool like dbgview.exe. So even though you don't have a console app, you can still get trace output (and unlike AfxMessageBox, TRACE won't effect window focus).
    Thanks for the quick responses. I'll have to agree with you, it appears that this is as far as I'm going to get as far as digging into the core of the issue. It sounds like we all coming to the same, hard to prove out conclusion, but since I can no longer get this to occur once I stop using the AfxMessageBox, I think that we can conclude that our speculations here are at least close to the mark in regards to whats happening.

    This still concerns me a little, as there might be need to use a message box to report an error in that method, which could cause this problem to manifest, but in general it seems that trying to avoid a long operation in the main thread is the proper course of action in this situation.

  3. #18
    Arjay's Avatar
    Arjay is online now Moderator / MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    10,967

    Re: MFC C++ multiple OnSetActive() calls happening at once

    Quote Originally Posted by cwhittier View Post
    This still concerns me a little, as there might be need to use a message box to report an error in that method, which could cause this problem to manifest, but in general it seems that trying to avoid a long operation in the main thread is the proper course of action in this situation.
    Yes. Putting up a message box is okay (because messages are still getting processed), the problem is after you block the ui thread for an extended period of time.

    That being said, if you recall my comment about what you are doing in OnSetActive - keep in mind to be careful about what you do here because you shouldn't necessarily initiate some operation in this handler. Like mentioned, users should be able to switch back and forth to your app and it shouldn't effect the operation of your app. If it does, perhaps there is something in a handler like OnSetActive that shouldn't be there.

  4. #19
    Join Date
    May 2013
    Location
    West Warwick, RI
    Posts
    8

    Re: MFC C++ multiple OnSetActive() calls happening at once

    Quote Originally Posted by Arjay View Post
    AfxMessageBox calls do take focus, so when they are dismissed the previous window will regain focus. It is puzzling about the order of when the set active messages occur, but keep in mind that you are sleeping the ui thread for a long period of time and your original code had an AfxMessageBox immediately coming out of the sleep. When you block the main thread, all sorts of messages get queued or ignored or their priorities get changed - some messages get processed before others, so it becomes very difficult to determine what exactly is going on (and there are additional checks in debug mode that don't happen in release, so that complicates things as well).

    So the bottom line here is to not block the main thread for any extended period. You can pump messages in the middle of your operation code, or use a worker thread.

    Last comment, in terms of using TRACE, keep in mind that if you are debugging inside the VS IDE, the trace statements will show up in the output window. If you are running the debug version of your app outside the debug window, the trace statements will show up in a tool like dbgview.exe. So even though you don't have a console app, you can still get trace output (and unlike AfxMessageBox, TRACE won't effect window focus).
    Thanks for the quick responses. I'll have to agree with you, it appears that this is as far as I'm going to get as far as digging into the core of the issue. It sounds like we all coming to the same, hard to prove out conclusion, but since I can no longer get this to occur once I stop using the AfxMessageBox, I think that we can conclude that our speculations here are at least close to the mark in regards to whats happening.

    This still concerns me a little, as there might be need to use a message box to report an error in that method, which could cause this problem to manifest, but in general it seems that trying to avoid a long operation in the main thread is the proper course of action in this situation.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center