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
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Odd MFC Dialog Executable Behavior

Odd MFC Dialog Executable Behavior

Scheduled Pinned Locked Moved C / C++ / MFC
debuggingcsharpc++visual-studiotesting
3 Posts 3 Posters 0 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.
  • W Offline
    W Offline
    wmallory
    wrote on last edited by
    #1

    I have a bit of strange behavior with a MFC application that I haven't seen before. The application is a simple MFC Dialog running unders Windows XP SP3 and using Visual Studio 2008. It builds fine under Debug and Release configurations. The Debug executable runs fine under the debugger and also within Visual Studio using the Start Without Debugging button. The Release executable runs fine directly from Windows. However, the Debug executable does NOT run fine directly from Windows. When double clicked from Windows Explorer, there is a brief hourglass and then what appears to be a quick exit. No messages, no nothing. Adding a few AfxMessageBox calls to the app's CWinAppEx class, it appears that not only does the app's InitInstance method not get called, but even the CWinAppEx constructor does not get called. Obviously, this makes debugging the problem somewhat difficult. Anyone seen similar behavior before? Seems like it might be a manifest problem of some sort, but I don't see why it would only affect the Debug executable and only directly from Windows. Additional Info: With a little more testing, I found that this behavior occurs even in a simple test application as soon as I add any code that requires an internally developed DLL. Note that if I rename this DLL, I get the usual can't find the DLL message. So the app is finding the DLL, but for some reason, in Debug configuration, there's a problem only when running directly from Windows.

    D C 2 Replies Last reply
    0
    • W wmallory

      I have a bit of strange behavior with a MFC application that I haven't seen before. The application is a simple MFC Dialog running unders Windows XP SP3 and using Visual Studio 2008. It builds fine under Debug and Release configurations. The Debug executable runs fine under the debugger and also within Visual Studio using the Start Without Debugging button. The Release executable runs fine directly from Windows. However, the Debug executable does NOT run fine directly from Windows. When double clicked from Windows Explorer, there is a brief hourglass and then what appears to be a quick exit. No messages, no nothing. Adding a few AfxMessageBox calls to the app's CWinAppEx class, it appears that not only does the app's InitInstance method not get called, but even the CWinAppEx constructor does not get called. Obviously, this makes debugging the problem somewhat difficult. Anyone seen similar behavior before? Seems like it might be a manifest problem of some sort, but I don't see why it would only affect the Debug executable and only directly from Windows. Additional Info: With a little more testing, I found that this behavior occurs even in a simple test application as soon as I add any code that requires an internally developed DLL. Note that if I rename this DLL, I get the usual can't find the DLL message. So the app is finding the DLL, but for some reason, in Debug configuration, there's a problem only when running directly from Windows.

      D Offline
      D Offline
      David Crow
      wrote on last edited by
      #2

      Does the "internally developed DLL" have any resources that are being used by the EXE or is it just exported functions that are being used?

      "One man's wage rise is another man's price increase." - Harold Wilson

      "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

      "Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

      1 Reply Last reply
      0
      • W wmallory

        I have a bit of strange behavior with a MFC application that I haven't seen before. The application is a simple MFC Dialog running unders Windows XP SP3 and using Visual Studio 2008. It builds fine under Debug and Release configurations. The Debug executable runs fine under the debugger and also within Visual Studio using the Start Without Debugging button. The Release executable runs fine directly from Windows. However, the Debug executable does NOT run fine directly from Windows. When double clicked from Windows Explorer, there is a brief hourglass and then what appears to be a quick exit. No messages, no nothing. Adding a few AfxMessageBox calls to the app's CWinAppEx class, it appears that not only does the app's InitInstance method not get called, but even the CWinAppEx constructor does not get called. Obviously, this makes debugging the problem somewhat difficult. Anyone seen similar behavior before? Seems like it might be a manifest problem of some sort, but I don't see why it would only affect the Debug executable and only directly from Windows. Additional Info: With a little more testing, I found that this behavior occurs even in a simple test application as soon as I add any code that requires an internally developed DLL. Note that if I rename this DLL, I get the usual can't find the DLL message. So the app is finding the DLL, but for some reason, in Debug configuration, there's a problem only when running directly from Windows.

        C Offline
        C Offline
        Code o mat
        wrote on last edited by
        #3

        Do you have the sources/project for this "internally developped DLL"? If yes, try the following: load the project for the DLL, build it and hit F5, VS should ask you to specify the executable you want to test your DLL with (if it doesn't, you can specify that somewhere in the project settings, can't recall where now), browse for your exe, select it and let it run (make it so it will load the DLL you just built, like, placing the executable right next to the DLL) and see if there are any exceptions thrown, check the debugger's output window too for any hints, maybe you will see something useful.

        > The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<

        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