I'm putting the finishing touches on a utility for our package. This utility is a MFC9 SDI app with a CFormView and all is well except that now the boss wants it to run minimized to the "tray" at startup. I added she ShellNotify stuff (I've done this dozens of times but never on a Doc/view app) and that all works well. The only problem is when the app is first run, it flashes a ever-so-brief window on the screen before settling down into its "hidden" state. Several searches have turned up little, but a few (one from CodeGuru itself here:http://www.codeguru.com/cpp/controls...cle.php/c5309/ pointed to the CSingleDocTemplate class as the likely culprit and that it should be overridden with a custom class that implements:
Which you can see defaults to TRUE on the bMakeVisible variable. I tried this and it basically hangs the app before anything is shown (I think maybe because I'm using MFC9 with CFrameWndEx/CWinAppEx and the article that this came from was back in the VC6 days). Perhaps I'm doing something wrong with my override so I'll include it before someone asks:
Yay! That was the key. I'd discovered the ActivateFrame() overload after digging through tons of MFC code, but the LoadWindowPlacement() overload was not as obvious (and not part of the list of "normal" overloads). I'd managed to fake it with:
in InitInstance(), but your solution is cleaner. Thanks.
Re: [RESOLVED] Can a Doc/view be hidden at startup?
I spent all morning searching for an answer to this same problem. My problem is that I was opening my MFC app as a separate process from a C# app, using Process.Start(ProcessStartInfo). No matter what I did, the MFC app would ignore the WindowStyle that I passed in (I tried passing WindowStyle.Hidden). I traced through all the MFC code and I thought I figured out what it was doing internally, I just didn't know how to fix it. I tried your solution and it worked, but I still couldn't figure out why. I put a breakpoint in my LoadWindowPlacement(...) override, and it hit me. Since I saw that this thread was so recent, I thought I'd let you in on what I found.
I was looking at CFrameImpl::RestoreWindowPosition(CREATESTRUCT&), which calls LoadWindowPlacement(...). Directly thereafter, if nCmdShow is anything but SW_MAXIMIZE, SW_MINIMIZE, SW_SHOWMINIMIZED, or SW_SHOWMINNOACTIVE, the framework would set nCmdShow to SW_SHOWNORMAL. Therefore, it would seem that you could NEVER start the app out hidden. However, if that were true, then this solution wouldn't work--setting nCmdShow to SW_HIDE still wouldn't help anything because once it returns, RestoreWindowPosition(...) will continue to set nCmdShow to SW_SHOWNORMAL. I stuck my breakpoint in and, sure enough, it did just that.
However, when I hit F5, I got into my LoadWindowPlacement(...) override again. It was called from CWinAppEx::LoadState(...). BUT, only
A quick search on m_bLoadWindowPlacement in MFC code led me to:
A simple call to EnableLoadWindowPlacement(FALSE) as the first line in my InitInstance() solved the problem. Try this out, and see if it does the trick for you, without all that extra work. I have to say, it didn't seem like performing such a simple task would require overrides of two different methods like that. The solution would HAVE to be something as simple as this.