![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I'm in the process of adding a bunch of new .NET functionality to a (poorly behaved) legacy MFC application. One of the things I'm adding is a "source code editor" (ala VBA): the window should minimize/restore separately from the main application, have its own menu/toolbar, etc. The first approach was straight-forward enough: create the "application" as a Form and use it as a modeless dialog. However, things didn't work right with menu keyboard accelerators and the like (Ctrl-C, Alt-X, F1), apparently a result of the main MFC application grabbing them. So, the approach that I've been using for the past several weeks is to create my own Application in a separate thread. See http://discuss.develop.com/archives/...0&F=&S=&P=3005 and http://forums.microsoft.com/MSDN/Sho...93220&SiteID=1. This has been working reasonably well, also having to Invoke() back to the main thread at times is a pain. However, I'm now seeing some crashes with very strange call stacks such as: System.OutOfMemoryException: Out of memory. at System.Drawing.Graphics.FromHdcInternal(IntPtr hdc) at System.Windows.Forms.PaintEventArgs.get_Graphics() at System.Windows.Forms.Control.PaintException(PaintE ventArgs e) at System.Windows.Forms.Control.PaintWithErrorHandlin g(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs) at System.Windows.Forms.Control.WmEraseBkgnd(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Mes sage& m) at System.Windows.Forms.ContainerControl.WndProc(Mess age& m) at System.Windows.Forms.UserControl.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) this seems to occur when the user tries to move my "application" window immediately after I've Invoke()d to the main thread. Also, I'd like a little bit better window management integration with the legacy MFC application; for example, I don't want one of its modal (error) dialogs to get hidden behind this editor application window. With that extensive background; the most recent thing I've tried is to use this top-level Form from MFC via the CWinFormsDialog<> class. After setting TopLevel=false on my Form, the form is displayed--although the results are quirky as I see two sets of non-client area items (close, minimize, maximize, etc.). But the bigger problem is that I can't get the keyboard accelerators working. I've overridden PreTranslateMessage() and tried calling Control.PreProcessMessage() (and the like), but it doesn't seem to work. At this point, I'm trying to figure out where to go next: sticking with a separate .NET Application in it's own thread is fine, but I've got no idea what could be causing the crash above. And even then, there are still glitches with getting windows "owned" correctly (and the legacy MFC application has it's own ideas too). Switching to MFC for at least some of the "application" shell (although as absolutely little as possible in MFC!) might help, but not if I can't get the keyboard accelerators. Is what I'm trying to do in MFC possible? supported? If not, what are the alternatives? My .NET UI has docking windows and MDI; I *really* don't want to have to do all that "shell" in MFC--even if the content are WinForms controls. Thanks for any tips/advice/pointers/etc. Dan |
#3
| |||
| |||
|
|
I remember a while ago I have a demo app in which I have my CHTMLView based app work on a windows form message pump... basically override CWinApp::Run and call Application::Start instead of calling CWinThread::Run . To make PretranslateMessage work I added my own IMessageFilter implementation to the application and call MFC's CWinApp::PreTranslateMessage in it. Haven't tested it extensively, though. -- Sheng Jiang Microsoft MVP in VC++ "Dan Smith" <Dan Smith (AT) nospam (DOT) nospam> wrote in message news FF43913-3DD5-4F32-AB53-9BDA2F5B04B5 (AT) microsoft (DOT) com...I'm in the process of adding a bunch of new .NET functionality to a (poorly behaved) legacy MFC application. One of the things I'm adding is a "source code editor" (ala VBA): the window should minimize/restore separately from the main application, have its own menu/toolbar, etc. The first approach was straight-forward enough: create the "application" as a Form and use it as a modeless dialog. However, things didn't work right with menu keyboard accelerators and the like (Ctrl-C, Alt-X, F1), apparently a result of the main MFC application grabbing them. So, the approach that I've been using for the past several weeks is to create my own Application in a separate thread. See http://discuss.develop.com/archives/...0&F=&S=&P=3005 and http://forums.microsoft.com/MSDN/Sho...93220&SiteID=1. This has been working reasonably well, also having to Invoke() back to the main thread at times is a pain. However, I'm now seeing some crashes with very strange call stacks such as: System.OutOfMemoryException: Out of memory. at System.Drawing.Graphics.FromHdcInternal(IntPtr hdc) at System.Windows.Forms.PaintEventArgs.get_Graphics() at System.Windows.Forms.Control.PaintException(PaintE ventArgs e) at System.Windows.Forms.Control.PaintWithErrorHandlin g(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs) at System.Windows.Forms.Control.WmEraseBkgnd(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Mes sage& m) at System.Windows.Forms.ContainerControl.WndProc(Mess age& m) at System.Windows.Forms.UserControl.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) this seems to occur when the user tries to move my "application" window immediately after I've Invoke()d to the main thread. Also, I'd like a little bit better window management integration with the legacy MFC application; for example, I don't want one of its modal (error) dialogs to get hidden behind this editor application window. With that extensive background; the most recent thing I've tried is to use this top-level Form from MFC via the CWinFormsDialog<> class. After setting TopLevel=false on my Form, the form is displayed--although the results are quirky as I see two sets of non-client area items (close, minimize, maximize, etc.). But the bigger problem is that I can't get the keyboard accelerators working. I've overridden PreTranslateMessage() and tried calling Control.PreProcessMessage() (and the like), but it doesn't seem to work. At this point, I'm trying to figure out where to go next: sticking with a separate .NET Application in it's own thread is fine, but I've got no idea what could be causing the crash above. And even then, there are still glitches with getting windows "owned" correctly (and the legacy MFC application has it's own ideas too). Switching to MFC for at least some of the "application" shell (although as absolutely little as possible in MFC!) might help, but not if I can't get the keyboard accelerators. Is what I'm trying to do in MFC possible? supported? If not, what are the alternatives? My .NET UI has docking windows and MDI; I *really* don't want to have to do all that "shell" in MFC--even if the content are WinForms controls. Thanks for any tips/advice/pointers/etc. Dan |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |