糖果派对官方网站_可以赌钱的糖果游戏_手机版
windows窗口分析,父窗口,子窗口,所有者窗口

windows窗口分析,父窗口,子窗口,所有者窗口

作者:网络编程    来源:未知    发布时间:2019-12-23 19:49    浏览量:

bb电子糖果派对 1

(本文尝试通过一些轻易的尝试,来分析Windows的窗口机制,并对微软的希图理由实行自然的估量,须求读者具备C++、Windows编制程序及MFC资历,还得有一定出手才具。文中恐怕现身实时势部术语不统意气风发的现象,举个例子“子窗口”,不常候笔者撰文“child window”,不常候写作“child”,小编想应该不会有太大影响,小说太长,不后生可畏意气风发改进了)

窗口的品格是用叁个叁十四个人整数来代表的,如下所示:*WindowStyles*/#defineWS_OVERLAPPED0x00000000L#defineWS_POPUP0x80000000L#defineWS_CHILD0x40000000L作者的难题是,头文件WinUser.h中只定义到了前三个人,最终两个是#defineWS_MAXIMIZEBOX0x00010000L。不过日常用spy++见到局地窗口的后四人也许有定义,但spy++也识不了,只可以用数值表示。如下图:请教:怎么着能查到那后多少人终究表示些什么看头?谢谢。

主题材料开头于自己的近年的贰遍支付阅世,我希图把程序的生机勃勃部分界面放在DLL中,而那有的分界面又要求使用到Tooltip,但DLL中的虚函数PreTranslateMessage不可能被调用到,原因大家可以在网络查找一下,那并非自个儿那篇文章要讲的。PreTranslateMessage不能够被调,那Tooltip也就无法起效果,因为Tooltip需求在PreTranslateMessage中走入tooltip.RelayEvent(&msg卡塔尔(英语:State of Qatar)来触发事件,方可不荒谬展现。化解方式有一点个,笔者用的是相比麻烦的二个——完全本人手动编写Tooltip,然后用WM_MOUSEMOVE等事件来触发Tooltip显示,写好未来察觉些小意思,那便是调解运转时候IDE给了个warning,说作者在析构函数中调用了DestroyWindow,那样会形成窗口OnDestry和OnNcDestroy不被正常调用,那一个标题本身从前碰着过,当然肃清办法也是肯定的,只须求在窗口对象(C++概念,非Windows内核对象,下文同)销毁前,调用DestroyWindow就可以。对于要销毁的那些窗口的子窗口,是不供给显式调用DestroyWindow的,因为父窗口在销毁的时候也会销毁掉它们,OK,小编把这几个历程用个暗指图说Bellamy下:

bb电子糖果派对 2

图1

上航海用图书馆表示了App Window及其子窗口的关联,以往假设大家要绝迹Parent Window 1(对应的对象指针是m_pWndParent1),咱们可以m_pWndParent1->DestroyWindow(卡塔尔(قطر‎,那样Child Window 1,Parent Window 2,Child Window 2都被销毁了,销毁的时候那么些窗口的OnDestry和OnNcDestroy都被调用了,最终delete m_pWndParent1,此时m_pWndParent1->m_hWnd已是NULL,不会再去调用Destroy,在析构的时候也就不会现出Warning。但假若不先试行m_windows窗口分析,父窗口,子窗口,所有者窗口。pWndParent1->DestroyWindow()而直接delete m_pWndParent1,那么在CWnd::~CWnd中就能够调用DestroyWindow(m_hWnd卡塔尔(英语:State of Qatar),那样会发生WM_DESTROY和WM_NCDESTROY,会尝试去调用OnDestry和OnNcDestroy,但由于是在CWnd的函数bb电子糖果派对,~CWnd(卡塔尔(英语:State of Qatar)的中间调用那七个分子,那时的虚函数表指针并不指向派生类的虚函数表,由此调用的莫过于是CWnd::OnDestroy和CWnd::OnNcDestroy,派生类的OnDestry和OnNcDestroy不被调用,但大家有的是时候把自由内存等操作写在派生类的OnDestroy和OnNcDestroy中,那样,就轻便引致内部存款和储蓄器走漏和逻辑混乱了。

地点这么些道理我本来是精晓的,但Warning仍然现身了,并且笔者用杀绝法鲜明了是跟自身写的非常Tooltip有关,下边是有关我的Tooltip的截图:

bb电子糖果派对 3

图2

世家收看,Tooltip呈现在自己的图样窗口上,它是个弹出式(popup)窗口,其内容为当前鼠标光标的坐标值,图形窗口之外,小编是不想让它呈现的,那么依照自身的思绪,Tooltip就相应设计是图片窗口的子窗口,它的窗口对象就应有作为图形窗口对象的成员,在图纸窗口OnCreate的时候创建,在图片窗口被DestroyWindow的时候自动销毁,前边提到过,父窗口被销毁的时候,其子窗口会被机关销毁,没有错吗,所以不须求显式去对Tooltip调用DestroyWindow。可事实注解了那般是有标题标,因为Tooltip的父窗口根本不是,也无法是图形窗口。大家能够看出自个儿的图片窗口是作为二个子窗口嵌入到其余窗口中去的,它的性子包蕴了WS_CHILD,通过试验,作者发掘Tooltip的父窗口只好钦命为顺序主窗口,假设图谋钦赐为非常图形窗口的话,它就机关形成程序主窗口,再进一层研商发掘,弹出式窗口的父窗口都不可能是带WS_CHILD风格的窗口,然后展开spy++查看,弹出式窗口的上超级都是桌面,可是,通过GetParent函数,拿到的弹出式窗口的父窗口却是程序主窗口并非桌面,为何?……难点愈加多,小编糊涂了,下边说的都以在自己深深精晓前,所观望的情景,蕴含了本身的有的定义认知方面包车型客车错误。

好啊,大家明天始于,一丢丢地经过试验去攻破那些难题!

一、神秘的WS_OVERLAPPED

咱俩从WinUser.h头文件中可以看出,窗口可分三种,其Window Styles定义如下:

  1. #define WS_OVERLAPPED       0x00000000L
  2. #define WS_POPUP            0x80000000L
  3. #define WS_CHILD            0x40000000L

那么大家比较轻便得到那个结论:style的最高位是1的,是一个popup窗口,style的次高位是1的,代表是一个child窗口,借使最高位次高位都以0,这那些窗口正是八个overlapped窗口,假诺两位都以1,厄……MSDN告诉我们不能够这么干,事实吗?作者背后再讲。其实这一个结论是有一些过时的,甚至很能误导人,不是大家的由来,很可能是Windows的野史由来,为何?具体也是末端讲。嘿嘿。

OK,我们前日初叶来品尝,看看这么些风格终究影响窗口几何,对了,筹划spy++,那是尤为重要工具。

用VC++的起始创立二个Hello World的Windows程序,注意是Windows程序,不是MFC的Hello World,那样我们得以绕开MFC,专一于查看一些Windows的才干细节,编译,运维。

bb电子糖果派对 4

图3

接下来用spy++查看那么些窗口的风格,发掘其作风显示为“WS_OVERLAPPEDWINDOW|WS_VISIBLE|WS_CLIPSIBLING|WS_OVEGL450L应用程式ED”。那时它的创导函数为:

  1. hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

只制订了二个WS_OVE揽胜LAPPEDWINDOW,但我们神速就找到了WS_OVERLAPPEDWINDOW的定义:

  1. #define WS_OVERLAPPEDWINDOW (WS_OVERLAPPED     | /
  2.                              WS_CAPTION        | /
  3.                              WS_SYSMENU        | /
  4.                              WS_THICKFRAME     | /
  5.                              WS_MINIMIZEBOX    | /
  6.                              WS_MAXIMIZEBOX)

本来overlapped窗口正是有标题,系统菜单,最小最大化按键和可调动大小边框的窗口,这么些概念是科学的,但只是个大家心得上的定义的主题材料,因为popup和child窗口也如出风流罗曼蒂克辙能够具有这一个(前面申明)。由于WS_OVEMuranoLAPPED为0,那大家是否足以把WS_OVEWranglerL应用程式EDWINDOW定义中的WS_OVE卡宴LAPPED拿掉啊?那是迟早的,那也即是说WS_OVEXC90L应用程式ED什么都不是!大家只作popup和child的区分,是或不是那样?亦不是,大家再而三尝试。

异常粗略,接下去大家只给那些向导生成的代码加一丢丢东西,正是把CreateWindow改成:

  1. hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW|WS_POPUP, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

对,给窗口作风增一个popup风格,看看会什么?运营!这回可特别,窗口缩到了显示器的左上角,并且宽度中度都变成了非常的小,当然,你要么能够用鼠标拖动窗口边缘来调动它的朗朗上口的。如图:

bb电子糖果派对 5

图4

那是干吗吧?观看CreateWindow的,第四、第五、第六和第七参数,分别为窗口的x坐标,y坐标,宽度,和惊人,CW_USEDEFAULT被define成0,所以窗口被缩到左上角去也就不意外了,可不曾popup,光是overlapped风格的窗口,为啥不会缩呢?看MSDN的表达,对第八个参数的辨证:“If this parameter is set to CW_USEDEFAULT, the system selects the default position for the window's upper-left corner and ignores the y parameter. CW_USEDEFAULT is valid only for overlapped windows; if it is specified for a pop-up or child window, the x and y parameters are set to zero. ”别的多少个参数也是有形似的陈述,那注解了怎么?表达Windows对overlapped和popup依旧作区分的,而那点,算是大家开采的首先个差别。哦,还应该有件业务,正是用spy++观看其作风,开采其确实多了叁个WS_POPUP,别的没什么变化。

后续,那回或然老地方,把WS_POPUP改为WS_CHILD,试试看,那回创立窗口失利了,再次来到0,用GetLastError查看具体错误新闻,得到的是:“1406:不可能创建最上层子窗口。”看来桌面是不让大家不管搞的。继续,依然老地方,那回改成:

  1. hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW|WS_POPUP|WS_CHILD, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

啊?有没搞错,又是popup又是child,鲜明无法成功吗,不试不知底,居然成功了,这么些创设出来的窗口乍生机勃勃看,跟popup风格的很像,但用起来有一点点蹊跷,比方:当它被别的窗口挡住的时候,不可能因此点击它的顾客区来让它展现在前头,尽管点击它的标题栏,也是要松手鼠标左键,它手艺呈现在头里,还大概有正是用spy++的“瞄准镜”没办法准确捕捉到这些窗口,瞄准镜照准它的时候,就体现Caption为“Program Manager”,class为“Program”,“Program Manager”是如何?其实就是大家所见到的这些桌面(注意,不是桌面,作者说的是大家说“看见的桌面”,就是展现桌面Logo的那几个所能看见的桌面窗口,和前面提到的桌面窗口是有分其他)的父窗口的父窗口,这几个窗口平日景况下是不可能直接“照准”到的,那一点能够经过spy++证实,如图:

bb电子糖果派对 6

图5

bb电子糖果派对 7

图6

spy++无法一直“对准”这些popup和child并存的怪窗口,但大家有其他艺术捕捉到它,<Alt>+<F3>,输入窗口的标题来探究(记得运转程序后刷新一下本事找到),结果见下图:

bb电子糖果派对 8

图7

我们从上海体育场所中通晓地来看,popup和child并存!用spy++各种查看桌面窗口的属下,这种情景可能刚刚的,但这么的窗口代表了如何意义,小编就不知晓了,总的来讲用起来怪怪的,对Microsoft来讲,那或然正是Undocumented,OK,我们询问到这里就能够了,但貌似境况下,大家毫不去创立这种意外的窗口。这几轮实验给大家如何启迪?设计上的启迪:二个应用程序的主窗口经常是三个Overlapped类型的窗口,当然有时可以是四个popup窗口,比方依照对话框的次第,但不应有是二个child窗口,固然地点演示了怎么着给应用程序主窗口参加child风格。

那还只怕有一个主题材料,作者何以感到WS_OVE景逸SUVL应用程式ED神秘呢?那还算是拜spy++所赐,依据大家平常的主见,借使一个窗口的风格的参天两位都是0,它既不是popup亦不是child的时候,那它便是Overlapped。事实上spy++的判定不是如此的,就以刚才的实行为例,当使用WS_OVERLAPPEDWINDOW|WS_POPUP风格创立窗口的时候,WS_OVERLAPPED和WS_POPUP属性同不平时间现身了,作者做了重重浩大的尝尝,盘算寻觅里面规律,看看spy++是怎么推断WS_OVERL应用程式ED的,但现今没定论,笔者到MSDN上search,未果,有人谈起那个标题,但未曾令自个儿乐意的答疑,上面这段文字是笔者找到的也有一点点线索的回答:

Actually, Microsoft Spy++ is wrong.
There are two bits in the window style that control its type. If the high-order bit of the style DWORD is set, the window is a popup window. If the next bit is set, the window is a child window. If neither is set, the window is overlapped. (If both are set, the result is undocumented.)

Look at these definitions from WinUser.h.

  1. #define WS_OVERLAPPED       0x00000000L
  2. #define WS_POPUP            0x80000000L
  3. #define WS_CHILD            0x40000000L

Your window style (0x94c00880) has the high-order bit set and the next bit clear so it is a popup window, not an overlapped window.

The correct way to identify all three types of windows (this is what Spy++ should do) is

  1. dwStyle = GetWindowLong(hWnd, GWL_STYLE);
  2. if (dwStyle&WS_POPUP)
  3.  // it's a popup window
  4. else if (dwStyle&WS_CHILD)
  5.  // it's a child window
  6. else
  7.  // it's an overlapped window

那断描述跟自个儿的主见相符。要掌握,即便你只给窗口二个WS_POPUP的风格,WS_OVE凯雷德L应用软件ED也会显得在spy++上的,小编感到那非常常有标题,究竟spy++怎样判,预计得请教Bill盖茨了。还会有生机勃勃段有意思的描述,推断也存有助于:

As long as... 
WS_POPUP | WS_OVERLAPPED
...is absolutelly equivalent with...
WS_POPUP
... why do you care if Spy++ lists WS_OVERLAPPED or not?

Please stop playing "Thomas Unbeliever" with us.
Becomes too expensive to use "walking on the water" device here again, and again. ;)

固然如此那样说,小编照旧以为,spy++给了大家广大误导,那么对WS_OVEEscortLAPPED的探讨就一时小憩吧,作为三个技明星,很难容忍自身没辙通晓的逻辑,笔者就是这样种人……然则假若再扯下去的话那篇作品就不可能终止了,所以姑且感觉,这是spy++的错,而大家照旧感觉窗口分3种——popup,child和Overlapped。(Undocumented不在这里列,也不在本文陈诉之列)

二、Parent与Owner

那是内容最多的意气风发节,做好心情希图。

微软塌塌大家开了个玩笑,告诉大家,窗口和人肖似,可以有老人,有持有者……大家先来看一个最盛名的Windows API:

  1. HWND CreateWindowEx(
  2.   DWORD dwExStyle,      // extended window style
  3.   LPCTSTR lpClassName,  // registered class name
  4.   LPCTSTR lpWindowName, // window name
  5.   DWORD dwStyle,        // window style
  6.   int x,                // horizontal position of window
  7.   int y,                // vertical position of window
  8.   int nWidth,           // window width
  9.   int nHeight,          // window height
  10.   HWND hWndParent,      // handle to parent or owner window
  11.   HMENU hMenu,          // menu handle or child identifier
  12.   HINSTANCE hInstance,  // handle to application instance
  13.   LPVOID lpParam        // window-creation data
  14. );

猜对了,小编正是从MSDN上copy下来的,看第七个参数的名字叫hWndParent,从名称想到所满含的意义哦,那就是Parent窗口了,但是我们中夏族民共和国人不希罕称之“父母窗口”,我们钟爱叫它“父窗口”,轻易一点。其实这一个名字对大家变成了多数的误导,小编一定要说,恐怕也是出于历史原因,举个例子在Windows 1.0(1985年出的,那个时候没什么影响力)的时候,唯有Parent这些概念,未有Owner的定义。

回头看看作品初阶动和自动小编说到的,作者思量将Tooltip的父窗口设置为一个图纸窗口,必须要负众望,Tooltip的父窗口会自动成为应用程序主窗口,那是怎么?好,今后上马讲概念了,都以自家花了广大时日在网络络查究,筛选,确认,得出去的定论:

平整黄金年代:Owner window调整了Owned window的生活,当Owner window被灭亡的时候,其所属的Owned window就能够被销毁。
准绳二:Parent window控制了Child window的绘图,Child window不大概来得在其Parent window的顾客区之外。
平整三:Parent window同有的时候候决定了Child window的生存,当Parent window被毁灭的时候,其所属的Child window就能够被销毁。
规则四:Owner window不能是Child window。
平整五:Child window一定有Parent(不然怎么叫Child?),一定未有Owner。
平整六:非Child window的Parent一定是桌面,它们不确定有Owner。

那是相比主要的几点,若是您感觉那跟你早前学到的,或然咀嚼的不完全相仿,先别急着抗议,先看看自身是怎么领会的。除了这几条准绳,上面作者还有可能会日趋交给一些规行矩步。

先说相比较好精通的Child window,上文提到了,富含了WS_CHILD风格的窗口就叫Child window,咱们中文叫“子窗口”。那么笔者后面提到的自己写的可怜Tooltip,是还是不是“子窗口”呢?——当然不是了,它从不WS_CHILD风格啊,它是popup风格的,笔者想当然地以为在创建它的时候给它钦定了格外Parent参数,这它的Parent便是非常参数,其实是错的。这一个试验最简单易行了,随意找些应用程序,举例“附件”里的总括器,用spy++的“瞄准镜”旁观地点的开关等“子窗口”,在Styles标签中,大家得以看来WS_CHILD(或者WS_CHILDWINDOW,同样的)属性,然后在Windows标签中,大家得以领略地观望,凡是含有了WS_CHILD属性的窗口(子窗口),都未曾Owner window,不相信仍然是能够一而再侦查别的应用程序,省去自身编制程序了。再看它们的Parent window,是还是不是明确有的?——当然一定有。

后面说了,子窗口不能够呈现在父窗口顾客区之外,大家最广大的子窗口就是那个摆在对话框上的控件,什么button啊,listbox啊,combobox啊……都有个联合特征,不可能拖动的,除非你重写它们的window procedure,然后响应WM_MOUSEMOVE等音信,落成所谓“拖动”。那么有未有能够像应用程序主窗口那样有标题栏,能够被随便拖动的子窗口呢?——当然有!要成立是吧?简单,直接用MFC向导成立多少个MDI程序就可以,MDI的那多少个View其实正是能够跋扈拖动的子窗口,能够用spy++查看一下它们的属性,当然,你是无法把它们拖出主窗口的客商区的。大概你跟自家同样,感觉MFC封装了过多的工夫细节,想完全本身手动成立叁个能拖动的子窗口,并且看起来就好像个MDI的分界面,OK,follow me。

率先当然是用应用程序向导生成最缩手观看的Window应用程序了。然后扩充多个窗口管理函数,也便是大家思谋开创的子窗口的管理函数了。

  1. LRESULT CALLBACK WndProcDoNothing(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
  2. {
  3.  return DefWindowProc(hWnd, message, wParam, lParam);
  4. }

DoNothing?好名字。注册之:

  1.  WNDCLASSEX wcex;
  2.  wcex.cbSize = sizeof(WNDCLASSEX); 
  3.  wcex.style         = CS_HREDRAW | CS_VREDRAW;
  4.  wcex.lpfnWndProc   = (WNDPROC)WndProcDoNothing;
  5.  wcex.cbClsExtra    = 0;
  6.  wcex.cbWndExtra    = 0;
  7.  wcex.hInstance     = hInstance;
  8.  wcex.hIcon         = LoadIcon(hInstance, (LPCTSTR)IDI_ALLWINDOWTEST);
  9.  wcex.hCursor       = LoadCursor(NULL, IDC_ARROW);
  10.  wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
  11.  wcex.lpszMenuName  = NULL; //子窗口不可能抱有菜单,钦赐了也未有用
  12.  wcex.lpszClassName = TEXT("child_window");
  13.  wcex.hIconSm       = LoadIcon(wcex.hInstance, (LPCTSTR)IDI_SMALL);
  14.  RegisterClassEx(&wcex);

聊到底当然是把它给创造出来了:

  1.  g_hwndChild = CreateWindowEx(NULL, TEXT("child_window"), TEXT(""), WS_CHILD|WS_VISIBLE|WS_OVERLAPPEDWINDOW|WS_CLIPSIBLINGS, 30, 30, 400, 300, hWnd, NULL, hInstance, NULL);

关于WS_CLIPSIBLINGS属性,下文将涉嫌。好,就那样,我们看看运行作效果果:

bb电子糖果派对 9

图8

是否超级少蒙受这种窗口组织结构?确实超级少人这么用,而且哦,你会发掘子窗口的标题栏不能成为彩色,它一贯是灰的,就象征它直接处于未激活状态,你怎么点它,拖它,调它,都行不通的,而以当时候程序主窗口向来显示为激活状态,怎么着激活那么些子窗口?笔者已经对此心劳计绌,最终才清楚,子窗口是心有余而力不足被激活的,你即刻反对:“那MFC咋办到的?”哈哈,好,你影响够快,作者下文子禽给你演示怎么样“激活”子窗口。(注意是加引号的)未来尝试移动主窗口,你会发觉全部它的子窗口都会随着主窗口移动的,这就近似我们看苹果一败涂地同样,不会感觉奇异,但您有没有想过,主窗口移动的时候,其子窗口对显示屏的岗位也时有爆发了变通,不改变的是绝对主窗口的顾客区坐标。那正是子窗口的风味。再尝试看启用/禁止使用主窗口,突显/隐蔽主窗口看看,就简单得出结论:

平整七:子窗口会趁着其父窗口移动,启用/禁止使用,显示/隐讳。

子窗口大家就临时讲那么多,接着讲全部者窗口,就是Owner window,由于子窗口一定未有Owner,因而Owner window是对popup和Overlapped来说的,而popup和Overlapped前面也关乎了,不自然有Owner,不像Child那样料定有Parent。今后跻身大家下三个试验:

抑或用向导生成最平时的Windows hello world程序,步骤和上贰个尝试相当近似,仅仅改了一小点东西,改了哪点?就是把CreateWindowEx函数的第多少个参数的WS_CHILD拿掉,别的不改变,代码作者就不贴了,我们编写翻译并运营看看。我们拜会到雷同那一个作用:

bb电子糖果派对 10

图9

弹出窗口的caption是栗褐的,表达它地处激活状态,如果您未来点击程序主窗口,那弹出窗口的标题栏就变灰,而前后相继主窗口的标题栏变蓝,多少个窗口看起来就好像并列的涉及,但你快捷发掘它们其实不并列,因为假诺它们有肥胖部分的话,弹出窗口总是遮挡程序主窗口。用spy++阅览之,发掘先后主窗口正是弹出窗口的Owner。

平整八:非Child window总是呈现在它们的Owner在此以前。

拜见了没?这时候CreateWindowEx的第七个参数的意义就不是Parent window,而是Owner,这把那几个参数改为NULL,会有怎么着意义啊?立即试试看,反正这么轻松。

bb电子糖果派对 11

图10

初风姿罗曼蒂克看没什么变化,其实变化大了,一是主窗口那回可以显得在弹出窗口早先了,二是职分栏上现身了三个button。

bb电子糖果派对 12

图11

用spy++旁观到这七个窗口的Owner都是NULL。

平整九:Owner为NULL的非Child窗口可以(不是必定哦)在任务栏上现身它们的按键。

那个时候,你应当清楚怎么给三个Message博克斯正确钦点三个Owner这么主要了吧?笔者原先有个同事,特别“厉害”,他创制了叁个程序,蓬蓬勃勃旦现身点什么难题,就会把MessageBox弹得满屏都以,况兼把职责栏侵夺得渣都不剩,他大概是没精通那一个道理。MessageBox是二个非child窗口,如若不点名三个千真万确的Owner,那弹出MessageBox之后,Owner依然处于可操作的情形,七个窗口看起来是比量齐观的,都在职责栏上有展现,如若再弹出MessageBox,先关闭这个Message博克斯?我看先关哪个都没难题,因为分界面操作上未曾约束,但这么非常轻便导致逻辑混乱,如若不幸进入了个死循环,延续弹MessageBox,那仿佛这位同事写的百般程序那样,满屏都已音信框了。

大家后天来举香港行政局地微微复杂点点的实验,就是开创A弹出窗口,其Owner为主窗口,创造B弹出窗口,其Owner为A窗口,创制C弹出窗口,其Owner为B窗口。步骤模仿下边的窗口创设步骤就能够,好,编写翻译,运营,效果大致这么:

bb电子糖果派对 13

图12

当今,把主窗口最小化,看看发生了哪些专门的学问。你会发掘A窗口不见了,而B,C窗口尚在,A窗口毕竟是追随主窗口一块最小化了啊,只怕被销毁了啊?照旧被埋伏了吗?答案是被埋伏了,我们得以经过spy++找到它,发掘它的性子之中未有WS_VISIBLE。那今后将主窗口还原,A当时出现了,这以后大家相当的小化A,Oh?What happen?B不见了,主窗口和C都还在,大家依旧老方法,用spy++看B,开采它没了WS_VISIBLE属性,今后还原A窗口,方法如下图所示:

bb电子糖果派对 14

下一篇:没有了
友情链接: 网站地图
Copyright © 2015-2019 http://www.tk-web.com. bb电子糖果派对有限公司 版权所有