上のチュートリアルバグのActiveXの中で言及した、すなわち、メインウィンドウは、変数によって直接生成された場合、ウィンドウがクラッシュを引き起こすことが閉じられている
新世代方式の場合、すなわち、主、それは一時的な迅速な解決与えられ、崩壊しないだろう新しいウィンドウを生成するために使用され、_tWinMainは次のように読んで：
- int型APIENTRY _tWinMain（HINSTANCE hInstanceは、HINSTANCE hPrevInstance、LPTSTR lpCmdLine、int型nCmdShow）
- {
- CPaintManagerUI ::でsetInstance（hInstanceは）;
- HRESULT HR = ::のCoInitialize（NULL）。
- もし（FAILED（HR））の戻り0;
- =新しいCDuiFrameWnd CDuiFrameWnd * PFRAME; //ここで新しいこと、またはActiveXコントロールがある場合に、クラッシュを引き起こすために、ウィンドウを閉じる必要があります
- pFrame->作成（NULL、_T（ "DUIWnd"）、UI_WNDSTYLE_FRAME、WS_EX_WINDOWEDGE）。
- pFrame-> CenterWindow（）;
- pFrame-> ShowModal（）;
- PFRAMEを削除します。
- :: CoUninitializeの（）;
- 0を返します。
- }
根本的な理由は、ActiveXコントロールCOMは、このようにクラッシュを作成し、有効なもはやメモリに同様の方法を使用していますが、デストラクタで、その結果、スコープを制御していない、CActiveXCtrlメンバ変数m_pViewObjectということです。新しいメモリがあっても、オブジェクトの破壊後に、その記憶がまだ有効であるための新しい方法が出てクラッシュしない理由。
それは同様のCOMの挙動を使用しているので、そこにこれを削除し、いくつかありますが、Alberlは、Microsoft自身の内部COMを理解していないとActiveXがどのように対処するので、それはCOMとActiveX、もちろん、Alberlやデバッグduilibに評価することができませんでしたそして、私たちはCOM内部のいくつかのクラスActiveXUI.cppは参照カウント、アナログ的ですが、リリースカオス系列のいくつかのクラスは少しのように見え、それぞれがいくつかのクラスを含むことが、これはデストラクタをリードしてきましたことがわかりましたAlberl現在の焦点は、限定されたと組み合わせる入門チュートリアルを書く上で、短期的には根本的な問題を解決することはできません原因これらの問題、座席と他の友人~~~偉大な神
[ではじめに2013 duilib簡潔なガイド- Win32およびMFCと組み合わせ（16） ]このような使用は、MFCで発見された場合は、問題ありませんが、（^ O ^）/〜私たちは偉大な神〜を教えてください