none
相同的MFC程序,Win10和Win7差异很大 RRS feed

  • 问题

  • MFC程序,原来使用缺省的MFC的CMFCRibbonBar,程序在Win7和Win10环境下运行,结果完全一样。

    最近自己继承CMFCRibbonBar,改变了Ribbon的外观。现在win10环境下,与原来功能表现完全一致。但是到Win7下,出现了明显的差异。

    在Win7下,有如下重大的差异:

    1、鼠标拖拽标题,正常功能是拖动整个程序,win10下也是正常的。但是win7下,拖动的仅仅是Ribbon这一条形成的窗口,程序的其余界面不动。并且Ribbon这一条可以覆盖其它的DockablePane。

    2、点Ribbon上最大化和关闭,正常功能是最大化应用程序和关闭整个程序,win10下正常。但是Win7下,最大化和关闭的仅仅是新的Ribbon窗口。程序的其它部分不动,Ribbon区域关闭后不再刷新。

    请帮忙分析一下可能是什么原因导致的?Win7需要那些处理?

    2019年4月19日 8:30

全部回复

  • 补充一下观察到的现象,比如最大化窗口时候。一条指令,

    SendMessage(WM_SYSCOMMAND, SC_MAXIMIZE, 0);

    在Win10下是MainFrame响应的。但是在win7下,是Ribbon自己响应的,没有广播到MainFrame。如果换一种写法,

    ::SendMessage(AfxGetMainWnd()->GetSafeHwnd(), WM_SYSCOMMAND, SC_MAXIMIZE, 0);

    整个应用就会正常的最大化。

    但是鼠标拖拽移动窗口这些操作,没办法换成::SendMessage(HWND,...)这种形式。

    导致这个问题的原因可能是什么?Ribbon窗口的属性设置不对?还是vc类库的链接不对?或者头文件包含顺序不对?

    2019年4月19日 10:34
  • 再继续补充现象:

    再点ribbon上的最大化按钮,win7上的行为,ribbon这个窗口本身最大化了,占满了MainFrame的窗口。

    Win7和Win10,调用SendMessage(WM_SYSCOMMAND, SC_MAXIMIZE, 0);都是首先发送到Ribbon的HWND,在调用缺省的处理函数,最终交由MainFrame的HWND处理。让MainFrame最大化到占满桌面。

    从这个现象判断,会不会是窗口间父子关系、或者Owner关系导致的?怎么验证和调整呢?

    2019年4月19日 11:30
  • 再补充一下现象,如果在win7上,如果打开aero效果,即透明标题条显示的话,程序是正常的。

    如果关闭aero效果,计算机高级设置中,性能》视觉效果,选择最佳性能的话,就不正常。

    到程序中,如果打开aero,GetGlobalData()->IsDwmCompositionEnabled()返回true。关闭aero返回false。

    但是用原生mfcribbon, 关闭aero也可以正常工作。

    2019年4月20日 3:10
  • 你好,

    感谢您在MSDN论坛发帖提问。

    >>相同的MFC程序,Win10和Win7差异很大,请帮忙分析一下可能是什么原因导致的?Win7需要那些处理?

    AFX_GLOBAL_DATA :: IsDwmCompositionEnabled提供了一种简单的方法来调用 WindowsDwmIsCompositionEnabled。如果启用了桌面窗口管理器(DWM)组合,则为TRUE ; 否则,FALSE。

    启用桌面合成后,单个窗口不再像以前版本的Windows中那样直接绘制到屏幕或主显示设备。相反,他们的绘图被重定向到视频内存中的离屏表面,然后将其渲染成桌面图像并显示在显示器上。从Windows 8开始,始终启用DWM组合。DWM不能再以编程方式禁用,也不会在应用程序尝试绘制到主显示表面时禁用。

    如果应用程序在其清单中声明Windows 8兼容性,则此函数将通过pfEnabled接收值TRUE。如果未找到此类清单条目,则不会假定Windows 8兼容性,并且此函数通过pfEnabled接收值FALSE。这样做是为了使解释值为TRUE以暗示高对比度模式关闭的旧程序可以继续做出关于渲染其图像的正确决定。

    Best Wishes,

    Jeanine Zhang
    2019年4月22日 6:27
    版主