Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Modeless Dialog in DLL: Message Confusion

Modeless Dialog in DLL: Message Confusion

Scheduled Pinned Locked Moved C / C++ / MFC
helpc++debuggingquestion
2 Posts 2 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Justin Cooke
    wrote on last edited by
    #1

    Greetings All, I've been burning up all of my time over the past two days trying to debug this. Please help! I've written a DLL that creates a modeless dialog (in this case allowing the user to watch an aiming video image of a Laser Tracker.) This DLL is used by various client applications including my test app. I need the user to be able to use the arrow keys to "jog" the Tracker from the dialog. Also, all of the normal dialog keyboard control needs to work (tabbing, typing into CEdit boxes, etc.) At first, I couldn't even get key messages in the dialog...as soon as a key was pressed (with focus on the dialog), the message came to the client app. I found a way to fix this from MS' website involving having the app call a FilterDLLMsg() func from its PreTranslateMessage(). However, now when a key is pressed in the dialog, the dialog and app freeze. I spent a long time tracing this freeze and it seemed to be freezing around the MFC code for _AfxFindNextMnem. I was stumped and thought it had to do with a tabstop or group setting for my dialog controls. Then I tried changing the m_pMainWnd = &dlg; line in my client application's InitInstance() to m_pMainWnd = NULL;. (It's a dialog based app.) That corrected the freeze problem, but now any AfxMessageBoxes() I call from my client app seem to belong to the desktop instead of the main app dialog. There may be other, more serious, ramifications, but I haven't tested any further. So, I don't want to change the m_pMainWnd = &dlg; if I don't have to, but for now, it's the only way I've found to keep the DLL/app from freezing. Is that safe? I'd prefer a different solution. Has anyone out there ever seen this type of behavior? Any ideas? My brain is getting all mushy :~ as I haven't made much progress on this:confused: Thanks, Justin

    B 1 Reply Last reply
    0
    • J Justin Cooke

      Greetings All, I've been burning up all of my time over the past two days trying to debug this. Please help! I've written a DLL that creates a modeless dialog (in this case allowing the user to watch an aiming video image of a Laser Tracker.) This DLL is used by various client applications including my test app. I need the user to be able to use the arrow keys to "jog" the Tracker from the dialog. Also, all of the normal dialog keyboard control needs to work (tabbing, typing into CEdit boxes, etc.) At first, I couldn't even get key messages in the dialog...as soon as a key was pressed (with focus on the dialog), the message came to the client app. I found a way to fix this from MS' website involving having the app call a FilterDLLMsg() func from its PreTranslateMessage(). However, now when a key is pressed in the dialog, the dialog and app freeze. I spent a long time tracing this freeze and it seemed to be freezing around the MFC code for _AfxFindNextMnem. I was stumped and thought it had to do with a tabstop or group setting for my dialog controls. Then I tried changing the m_pMainWnd = &dlg; line in my client application's InitInstance() to m_pMainWnd = NULL;. (It's a dialog based app.) That corrected the freeze problem, but now any AfxMessageBoxes() I call from my client app seem to belong to the desktop instead of the main app dialog. There may be other, more serious, ramifications, but I haven't tested any further. So, I don't want to change the m_pMainWnd = &dlg; if I don't have to, but for now, it's the only way I've found to keep the DLL/app from freezing. Is that safe? I'd prefer a different solution. Has anyone out there ever seen this type of behavior? Any ideas? My brain is getting all mushy :~ as I haven't made much progress on this:confused: Thanks, Justin

      B Offline
      B Offline
      bikram singh
      wrote on last edited by
      #2

      If your problem is AfxMessageBox(), dont use it. Use MessageBox(dlg,"some text",0,0) instead. The desktop is the parent of the Message Box bcos MFC probably uses the m_pMainWnd, which you set to 0, as the first param to the MessageBox() function. I dont know why the dialog should freeze, cos i havent tried it yet. Bikram Singh

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups