------ Build started: Project: CompilerErrorC2872, Configuration: Debug Win32 ------

Compiling...
NamespaceOuterClass.cpp
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceOuterClass.cpp(8) : error C2872: 'CCommonClass' : ambiguous symbol
        could be 'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\CommonClass.h(7) : CCommonClass'
        or       'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(15) : Namespace::CCommonClass'
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceOuterClass.cpp(9) : error C2664: 'Namespace::CNamespaceInnerClass::CNamespaceInnerClass(Namespace::CCommonClass *)' : cannot convert parameter 1 from 'CCommonClass *' to 'Namespace::CCommonClass *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Generating Code...
Compiling...
NamespaceInnerClass.cpp
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.cpp(8) : error C2872: 'CCommonClass' : ambiguous symbol
        could be 'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\CommonClass.h(7) : CCommonClass'
        or       'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(15) : Namespace::CCommonClass'
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.cpp(9) : error C2511: 'Namespace::CNamespaceInnerClass::CNamespaceInnerClass(CCommonClass *)' : overloaded member function not found in 'Namespace::CNamespaceInnerClass'
        d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(18) : see declaration of 'Namespace::CNamespaceInnerClass'
Generating Code...

Build log was saved at "file://d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\Debug\BuildLog.htm"
CompilerErrorC2872 - 4 error(s), 0 warning(s)

---------------------- Done ----------------------

    Build: 0 succeeded, 1 failed, 0 skipped

// CNamespaceInnerClass.h

namespace Namespace
{

class CCommonClass;

class CNamespaceInnerClass
{
public:
 CNamespaceInnerClass(CCommonClass* arg_pCommonClass);
 ~CNamespaceInnerClass(void);

protected:
 CCommonClass* m_pCommonClass;

};

}

// CNamespaceInnerClass.h

class CCommonClass;    // namespace Namespace 밖으로 선언을 옮겼습니다.

namespace Namespace
{

 

class CNamespaceInnerClass
{
public:
 CNamespaceInnerClass(CCommonClass* arg_pCommonClass);
 ~CNamespaceInnerClass(void);

protected:
 CCommonClass* m_pCommonClass;

};

}

double x1[] = {-1.00, -1.00, -1.00, -1.00, -0.33, -0.33, 0.33, 0.33, 1.00, 1.00, 1.00, 1.00};
double x2[] = {-0.89, -0.89, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.89, 0.89};

// RepeatDataFilter.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <map>
#include <vector>
#include <string>

using namespace std;

template<typename T>
void RepeatDataFilter(const vector<T>& arg_refVtrInX1, const vector<T>& arg_refVtrInX2, vector<T>& arg_refVtrOutX1, vector<T>& arg_refVtrOutX2)
{
 map<string, int> mFilter;
 TCHAR szBuf[100];

 int nSize = (int) arg_refVtrInX1.size();
 for(int i=0; i<nSize; i++)
 {
  memset(szBuf, 0, sizeof(TCHAR));

  _stprintf(szBuf, _T("%f#%f"), arg_refVtrInX1[i], arg_refVtrInX2[i]);
  pair<string, int> item(szBuf, i);
 
  mFilter.insert(item);
 }

 map<string, int>::iterator it;
 for(it = mFilter.begin(); it != mFilter.end(); it++)
 {
  arg_refVtrOutX1.push_back(arg_refVtrInX1[it->second]);
  arg_refVtrOutX2.push_back(arg_refVtrInX2[it->second]);
 }
}

int _tmain(int argc, _TCHAR* argv[])
{
 double x1[] = {-1.00, -1.00, -1.00, -1.00, -0.33, -0.33, 0.33, 0.33, 1.00, 1.00, 1.00, 1.00};
 double x2[] = {-0.89, -0.89, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.89, 0.89};

 vector<double> vtrInitX1, vtrInitX2;
 vector<double> vtrX1, vtrX2;

 int nArr = (int) (sizeof(x1) / sizeof(double));

 for(int i=0; i<nArr; i++)
 {
  vtrInitX1.push_back(x1[i]);
  vtrInitX2.push_back(x2[i]);
 }

 RepeatDataFilter<double>(vtrInitX1, vtrInitX2, vtrX1, vtrX2);

 TRACE(_T("\n\n=========================================================\n\n"));
 size_t nSize = vtrX1.size();
 for(size_t i=0; i<nSize; i++)
 {
  TRACE(_T("\n%5.2f\t%5.2f"), vtrX1[i], vtrX2[i]);
 }
 TRACE(_T("\n\n=========================================================\n\n"));

 return 0;
}

=========================================================

-0.33  0.00
-1.00 -0.89
-1.00  0.00
 0.33  0.00
 1.00  0.00
 1.00  0.89

=========================================================

SYMPTOMS

Accelerator keys, such as ARROW keys, are first received by the message pump of the ActiveX control's container. Even if the control has the focus, it does not receive messages for keystrokes that have special meaning to control containers, such as ARROW and TAB keys. MFC ActiveX controls have a chance to intercept these messages by overriding their PreTranslateMessage function.

However, PreTranslateMessage is not always called for an MFC ActiveX control.

증상

화살표키와 같은 엑셀레이터 키들은 ActiveX control's container의 메시지 펌프로 처음 전달 됩니다. 비록 control이 포커스를 받고 있다고 하더라도 키보드 메시지는 control로 전달되어지지 않습니다. MFC ActiveX control들은 이러한 키보드 메시지를PreTranslateMessage 함수를 오버라이딩 하므로써 키보드 메시지를 가로챌 수 있습니다.

그러나, PreTranslateMessage는 MFC ActiveX control에서는 항상 호출 되지 않습니다.

CAUSE

PreTranslateMessage in an MFC ActiveX control is called by the TranslateAccelerator method of the IOleInPlaceActiveObject interface of the control. Internet Explorer only calls this method for the control that is currently UI-Active. Only one control can be UI-Active at a time.

Internet Explorer does not automatically UI-Activate any controls when a page is first loaded. Internet Explorer waits until the user tabs to an ActiveX control on the page to UI-Activate it. Also, MFC ActiveX controls UI-Activate themselves when they are clicked with the mouse. In an MFC ActiveX control, this is done in COleControl::OnLButtonUp.

If you have a child control inside your COleControl, mouse-click messages on the child control are not sent to the COleControl and MFC does not UI- Activate the ActiveX control, even though the child control has just been given the keyboard focus. Internet Explorer intercepts the keystrokes and does not give the control a chance to filter them in PreTranslateMessage.

원인

MFC ActiveX control의 PreTranslateMessage 함수는 control의 IOleInPlaceActiveObject interface의 TranslateAccelerator method에 의해서 호출 됩니다. Internet Explorer는 오직 현재 활성화 된 control을 위해 이 method를 호출합니다. 한 번에 오직 하나의 control만이 활성화 될 수 있습니다.

Internet Explorer는 웹 페이지가 처음으로 로드되었을 때 어떠한 control들도 자동으로 활성화 시키지 않습니다. Internet Explorer는 사용자가 user tabs(이게 사용자가 탭키를 누르는것을 이야기하는건지 아니면 다른 의미가 있는건지 모르겠네요 ㅡㅡ??) 웹 페이지의 ActiveX control을 활성화 시킬때 까지 대기합니다. 또한, MFC ActiveX controls 마우스 클릭을 통해서도 활성화가 됩니다.
MFC ActiveX control은 COleControl::OnLButtonUp 메시지가 완료되었을때 활성화 됩니다.

만약 당신의 COleControl이 내부에 child control (제가 소개한 클래스 다이어그램에서 CMyActiveXView에 해당합니다.)을 가지고 있고 마우스 이벤트가 child control에서 발생한다면 이 메시지는 COleControl에게 보내지지 않으며 MFC는 child control이 키보드 포커스를 가지고 있다고 하더라도 ActiveX control을 활성화 시키지 않습니다. Internet Explorer가 키보드 메시지를 가로채서 control이 PreTranslateMessage함수가 메시지를 가져올 기회를 주지 않기 때문입니다.

RESOLUTION

Here is a typical PreTranslateMessage. This code forwards ARROW, HOME, and END keys back to the control so that they can be received using a MESSAGE_MAP entry: 

   // trap keys and forward on to the control
   BOOL CMyActiveXCtrl::PreTranslateMessage(MSG* pMsg)
   {
      switch (pMsg->message)
      {
         case WM_KEYDOWN:
         case WM_KEYUP:
            switch (pMsg->wParam)
            {
               case VK_UP:
               case VK_DOWN:
               case VK_LEFT:
               case VK_RIGHT:
               case VK_HOME:
               case VK_END:
                  SendMessage (pMsg->message, pMsg->wParam, pMsg->lParam);
                  // Windowless controls won't be able to call SendMessage.
                  // Instead, just respond to the message here.
                  return TRUE;
            }
            break;
      }
      return COleControl::PreTranslateMessage(pMsg);
   }

해결

아래 코드는 일반적인 PreTranslateMessage함수 입니다. 이 코드는 화살표, HOME, 및 END 키들을 control의 MESSAGE_MAP 항목을 사용하여 받아 사용할 수 있도록 전달합니다.

저 같은 경우는 Enter키와 Tab키에서 CEdit control의 값을 얻어와야 하므로 위 MS 기술문서의 코드를 아래와 같이 고쳐서 사용하였습니다.

   // trap keys and forward on to the control
   BOOL CMyActiveXCtrl::PreTranslateMessage(MSG* pMsg)
   {
      switch (pMsg->message)
      {
         case WM_KEYDOWN:
         case WM_KEYUP:
            switch (pMsg->wParam)
            {
               case VK_TAB:
               case VK_RETURN:
                  pView->GetPoint();
                  return TRUE;
            }
            break;
      }
      return COleControl::PreTranslateMessage(pMsg);
   }

If you have a child control within your ActiveX control, you need to UI-Activate the whole control whenever that child control is activated. For example, if you have an edit control inside your ActiveX control, add a handler as follows to your ActiveX control class:

int CMyActiveXCtrl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
{
    if (!m_bUIActive)
        OnActivateInPlace (TRUE, NULL); // == UI-Activate the control
    return COleControl::OnMouseActivate(pDesktopWnd, nHitTest, message);
}

만약 당신의 ActiveX control이 child control을 가지고 있다면, 모든 control이 활성화 될 때는 언제나 child control도 활성화 될 필요가 있습니다. 예를 들어 만약 당신의 ActiveX control 내부에 edit control이 있다면, 아래 핸들러를 당신의 ActiveX control 클래스에 추가합니다.

Because Internet Explorer may not immediately UI-Activate a control, even if that is the only control on the page, it may be desirable to automatically request a UI-Activation when the control is created. This can be done during the COleControl::OnCreate (WM_CREATE) handler. Windowless controls do not get WM_CREATE or any windows messages; therefore, this code won't work in a windowless control. Also note that this does not guarantee that a control will remain UI-Activated. If there are other controls on a page that request UI-Activation in a similar manner, only one will eventually be UI-Activated and receive keystroke messages as described. And if the user TABs away from an ActiveX Control, Internet Explorer will automatically UI-deactivate the control.
int CMyActiveXCtrl::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
    if (COleControl::OnCreate(lpCreateStruct) == -1)
        return -1;
    OnActivateInPlace (TRUE, NULL); // == UI-Activate the control
    return 0;
}

Internet Explorer는 웹 페이지에 오직 control 뿐이라고 해도 즉시 control을 활성화 시키지 않기 때문에 control이 생성되자 마자 활성화 시키는 것이 바람직하다고 할 수 있겠습니다. 이 방법은 COleControl::OnCreate (WM_CREATE) handler를 통해서 구현 될 수 있습니다. 윈도우가 없는 control들은 WM_CREATE 또는 어떠한 윈도우 메시지도 받을 수 없기 때문에 윈도우가 없는 control의 경우 아래의 코드는 무의미합니다. 또한 이 코드가 control이 활성화를 유지하도록 보장하지는 않습니다. 만약 다른 control들이 웹 페이지 상에서 같은 방법으로 활성화 되었다면, 오직 하나만 마지막으로 활성화 될 것이고, 키보드 메시지를 받을 수 있을 것입니다. And if the user TABs away from an ActiveX Control, (해석이 안되네요 ㅡㅡ;;) Internet Explorer 자동으로 control을 활성화 시킬 것입니다.

#pragma once

#include "ModuleOne.h"
#include "ModuleTwo.h"

class CManager
{
public:
 CManager(void);
 ~CManager(void);
};

아래는 CManager클래스의 헤더파일을 포함하고 있는 CUser클래스의 cpp 내용입니다.

#include ".\user.h"
#include "Manager.h"

CUser::CUser(void)
{
}

CUser::~CUser(void)
{
}

------ Build started: Project: ForwardDeclaration, Configuration: Debug Win32 ------

Compiling...
User.cpp
Generating Code...
Skipping... (no relevant changes detected)
ModuleTwo.cpp
Manager.cpp
Linking...

아래는 CManager클래스의 헤더파일 내용입니다.

#pragma once

class CModuleOne;
class CModuleTwo;

class CManager
{
public:
 CManager(void);
 ~CManager(void);
};

아래는 CManager클래스의 헤더파일을 포함하고 있는 CUser클래스의 cpp 내용입니다.

#include ".\user.h"
#include "Manager.h"

CUser::CUser(void)
{
}

CUser::~CUser(void)
{
}

------ Build started: Project: ForwardDeclaration, Configuration: Debug Win32 ------

Compiling...
ModuleTwo.cpp
Generating Code...
Skipping... (no relevant changes detected)
Manager.cpp
Linking...

#define BUF  4
#define _BUF 6

     int nArray[BUF];
     ZeroMemory(nArray, sizeof(int) * _BUF);

// Dump.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

class CDump : public CObject
{
public:
 CDump(int i, int j)
 {
  this->i = i;
  this->j = j;
 }
 ~CDump() {}

#ifdef _DEBUG
 virtual void Dump(CDumpContext& dc) const
 {
  CObject::Dump(dc);

  dc<<_T("\n================= Start, CDump =================\n\n");
  dc<<_T("i : ")<<i<<_T("\n");
  dc<<_T("j : ")<<j<<_T("\n");
  dc<<_T("\n=================The end, CDump =================\n\n");
 }
#endif

protected:
 int i;
 int j;
};

int _tmain(int argc, _TCHAR* argv[])
{
 CDump* dump = new CDump(100, -100);

#ifdef _DEBUG
 //
 // CDumpContext 클래스의 전역 객체 변수 afxDump를 인자로 넘겨 줍니다.
 //
 dump->Dump(afxDump);
#endif

 delete dump;

 return 0;
}

 

#define ASSERT_VALID(pOb)  (::AfxAssertValidObject(pOb, THIS_FILE, __LINE__))

#ifdef _DEBUG
void AFXAPI AfxAssertValidObject(const CObject* pOb, LPCSTR lpszFileName, int nLine)
{
 if (pOb == NULL)
 {
  TRACE(traceAppMsg, 0, "ASSERT_VALID fails with NULL pointer.\n");
  if (AfxAssertFailedLine(lpszFileName, nLine))
   AfxDebugBreak();
  return;     // quick escape
 }
 if (!AfxIsValidAddress(pOb, sizeof(CObject)))
 {
  TRACE(traceAppMsg, 0, "ASSERT_VALID fails with illegal pointer.\n");
  if (AfxAssertFailedLine(lpszFileName, nLine))
   AfxDebugBreak();
  return;     // quick escape
 }

 // check to make sure the VTable pointer is valid
 ASSERT(sizeof(CObject) == sizeof(void*));
 if (!AfxIsValidAddress(*(void**)pOb, sizeof(void*), FALSE))
 {
  TRACE(traceAppMsg, 0, "ASSERT_VALID fails with illegal vtable pointer.\n");
  if (AfxAssertFailedLine(lpszFileName, nLine))
   AfxDebugBreak();
  return;     // quick escape
 }

 if (!AfxIsValidAddress(pOb, pOb->GetRuntimeClass()->m_nObjectSize, FALSE))
 {
  TRACE(traceAppMsg, 0, "ASSERT_VALID fails with illegal pointer.\n");
  if (AfxAssertFailedLine(lpszFileName, nLine))
   AfxDebugBreak();
  return;     // quick escape
 }
 pOb->AssertValid();
}

#if defined(_DEBUG) || defined(_AFXDLL)
 // Diagnostic Support
 virtual void AssertValid() const;
 virtual void Dump(CDumpContext& dc) const;
#endif

void CObject::AssertValid() const
{
 ASSERT(this != NULL);
}

// ASSERT_VALID.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

class Base : public CObject
{
 //
 // CRuntimeClass를 선언합니다.
 //
 DECLARE_DYNAMIC(Base)

 int i;
 
public:
 Base(int i) { this->i = i; }
 virtual ~Base() {}

#ifdef _DEBUG
 virtual void AssertValid() const
 {
  //
  // 자신의 상위 클래스의 AssertValid함수를 호출하여
  // 상위 클래스의 멤버 변수에 대한 유효성 검사를 수행합니다.
  //
  CObject::AssertValid();

  ASSERT(i > 0);
 }
#endif
};
//
// CRuntimeClass를 정의합니다.
//
IMPLEMENT_DYNAMIC(Base, CObject)

class Derived : public Base
{
 //
 // CRuntimeClass를 선언합니다.
 //
 DECLARE_DYNAMIC(Derived)

 int j;

public:
 Derived(int i, int j) : Base(i) { this->j = j; }
 virtual ~Derived() {};

#ifdef _DEBUG
 virtual void AssertValid() const
 {
  //
  // 자신의 상위 클래스의 AssertValid함수를 호출하여
  // 상위 클래스의 멤버 변수에 대한 유효성 검사를 수행합니다.
  //
  Base::AssertValid();

  ASSERT(j > 0);
 }
#endif
};
//
// CRuntimeClass를 정의합니다.
//
IMPLEMENT_DYNAMIC(Derived, Base)

int _tmain(int argc, _TCHAR* argv[])
{
 Base* p = new Derived(-1, -1);
 ASSERT_VALID(p);

 delete p;

 return 0;
}

 

BOOL IsKindOf(   const CRuntimeClass* pClass ) const;

우선, MSDN에서 이 함수를 설명하는 부분을 살펴보면 인자로 들어온 pClass(CRuntimeClass의 객체)와 현재 클래스와의 관계를 테스트하는데 사용한다고 합니다. 이때 서로 같으면 0이 아닌값 (TRUE)를 반환하며 같지 않으면 0을 반환합니다. 이 함수의 검사 대상인 pClass는 이 함수를 호출한 클래스의 CRuntimeClass 객체 일 수도 있고 또는 이 함수를 호출한 클래스를 상속받은 하위 클래스의 CRuntimeClass 객체일 수도 있다는 것입니다. ( 이 두 경우 모두 이 함수의 결과는 참을 반환 합니다. ) 이 함수는 오직 DECLARE_DYNAMIC, DECLARE_DYNCREATE, or DECLARE_SERIAL macro를 선언한 클래스에서만 사용이 가능합니다.
이 함수는 C++의 다형성 특징을 약화 시키기 때문에 광범위하게 사용되지는 않습니다. 대신 가상함수를 사용합니다. (이 부분에서 이 함수가 다형성 특징을 약화시키고 그 때문에 가상함수를 대신 사용하라는데 어떤 뜻인지 잘 모르겠네요 ㅡㅡ?)

※ 어설픈 영어 실력으로 인해 오역이 있을 수 있습니다.

// IsKindOf.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

class Base : public CObject
{
 DECLARE_DYNAMIC(Base)

public:
};
IMPLEMENT_DYNAMIC(Base, CObject)

class Derived : public Base
{
 DECLARE_DYNAMIC(Derived)
};
IMPLEMENT_DYNAMIC(Derived, Base)

class Other : public CObject
{
 DECLARE_DYNAMIC(Other)

public:
};
IMPLEMENT_DYNAMIC(Other, CObject)

int _tmain(int argc, _TCHAR* argv[])
{
 Base* p = new Derived;
 
 if(p->IsKindOf(RUNTIME_CLASS(Base)))
  _tprintf(_T("p객체는 Base 클래스의 하위 클래스 또는 Base 클래스 입니다.\n"));   // 이 내용이 출력 됩니다.
 else
  _tprintf(_T("p객체는 Base 클래스의 하위 클래스 또는 Base 클래스가 아닙니다.\n"));

 if(p->IsKindOf(RUNTIME_CLASS(Derived)))
  _tprintf(_T("p객체는 Derived 클래스의 하위 클래스 또는 Derived 클래스 입니다.\n"));  // 이 내용이 출력 됩니다.
 else
  _tprintf(_T("p객체는 Derived 클래스의 하위 클래스 또는 Derived 클래스가 아닙니다.\n"));

 if(p->IsKindOf(RUNTIME_CLASS(Other)))
  _tprintf(_T("p객체는 Other 클래스의 하위 클래스 또는 Other 클래스 입니다.\n"));
 else
  _tprintf(_T("p객체는 Other 클래스의 하위 클래스 또는 Other 클래스가 아닙니다.\n"));  // 이 내용이 출력 됩니다.

 delete p;

 return 0;
}

* 참고 문헌

    윈도우즈 MFC 프로그래밍 : 원리에서 활용까지 (정보문화사)

* 예제 프로젝트

    IsKindOf.zip
    

이 인자를 TRUE로 했을 경우 이 함수는 lpHandles 인자로 넘어 온 배열의 모든 커널 오브젝트의 상태가 sigaled가 되었을 때 리턴한다고 합니다. 만약 FALSE로 했을 경우 이 함수는 특정 커널 오브젝트가 signaled 상태가 되었을 때 리턴 한다고 합니다. 그리고 이 리턴값은 이 함수를 리턴하게 한 커널 오브젝트를 가리킨다고 합니다. - 즉, 리턴값은 lpHandles 인자로 넘어 온 배열에서 signaled 상태가 된 커널 오브젝트의 인덱스 입니다. -

※ 어설픈 영어 실력으로 인해 오역이 있을 수 있습니다.

UINT WINAPI ThreadProc(LPVOID lpParam)
{
 DWORD* waitTime = (DWORD*) lpParam;
 
 Sleep(*waitTime);

 return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
 enum {THREAD_1, THREAD_2};
 HANDLE hArrThread[2];
 
 DWORD waitTime_1 = 3000;
 DWORD waitTime_2 = 1000;

 hArrThread[THREAD_1] = (HANDLE) _beginthreadex(NULL, 0, ThreadProc, (LPVOID) &waitTime_1, 0, NULL);
 hArrThread[THREAD_2] = (HANDLE) _beginthreadex(NULL, 0, ThreadProc, (LPVOID) &waitTime_2, 0, NULL);

 assert(NULL != hArrThread[THREAD_1] && NULL != hArrThread[THREAD_2]);

 //
 // WaiftForMultiPleObjects의 두번째 인자를 FALSE로 셋팅하면
 // 먼저 signal 상태로 전이 된 쓰레드의 핸들 배열 Index를 반환 한다.
 //
 switch(WaitForMultipleObjects(2, hArrThread, FALSE, INFINITE))
 {
 case THREAD_1:
  _tprintf(_T("The ended the THREAD_1.\n"));
  break;

 case THREAD_2:
  _tprintf(_T("The ended the THREAD_2.\n"));
  
  break;

 case WAIT_TIMEOUT:
 case WAIT_ABANDONED:
  return -1;
 }

 CloseHandle(hArrThread[THREAD_1]);
 CloseHandle(hArrThread[THREAD_2]);

 return 0;
}