IPC 여러 가지 구현방법 중에 WM_Copydata로 불리는 것

요즘 만들고 있는 테스트 툴에서 이른바 IPC (Inter Process Communication)이 필요해서 여러 가지 대안들을 검색해 보았다.

요구사항 첫번째는

윈도우 실행파일.exe param1

이런 식으로 실행시켰을 때는 Param1을 읽어서 그 mode로 동작하게 되며,

이미 기존 실행파일이 실행되고 있는 경우에 다시

윈도우 실행파일.exe param1로 실행시키는 경우 기존 실행 파일의 mode가 변경되는 요구사항이었다.

먼저 AutoIT 실행 파일에 인자를 주어 실행하는 경우 $CmdLine 배열이 넘어 오는데 이것까지는 문제가 없다.

하지만, 이후에 이 넘어온 인자를 다시 이미 실행중인 프로세스에 어떻게 전달할 것인가 하는 문제가 있다.

포럼 검색을 통해 여러 가지 방법이 제안되고 있는 것을 확인할 수 있었는데 그 중 다음의 방법이  Server - Client 방식을 필요로 하지 않는 경우에 적당하다고 판단되어 테스트 해보았다.

UDF 내용을 보면  Hidden으로 GUI를 만들고 그 Edit Field에 값을 넣고 윈도우 메시지를 이용해서 Notify를 날려주는 것으로 보인다. 동일 UUID로 start를 하려다가 에러가 나면 이미 동일한 UUID의 프로세스가 있다고 보고 Send Message를 해주면, 기존 프로세스에서 돌던 GUI 메시지 루프에서 Notify를 받아서 그 값을 읽어오는 구조를 통해 프로세스간 통신을 구현하고 있다.

내가 개발하고 있는 프로그램에서는 이 예제 그대로가 잘 작동하지 않아서 (기존 프로세스가 있는지 체크하는 부분) 내장 UDF 중에 _Singleton을 사용해서 이미 동일한 프로세스가 동작하고 있는지 판단하고 동작하고 있다면 WM_Copy를 이용해서 실행 인자를 날리면 기존 프로세스에서 GUI 메시지 루프 내에서 Select - Case 문을 통해 감지해서 실행 인자를 읽어오도록 하였다.

즉,

1. 실행 중인 프로세스가 있다면 _Singletone을 통해서 판단해서 Send Message를 날리고

2. 1번 조건에 해당하지 않지만 $CmdLine[0] = 1 이라면 실행 인자가 있는 것이므로 그 인자를 가지고 모드 설정을 하면 되었다.

현재 클라이언트 - 서버 구조로 테스트 툴을 만들고 있는데 그곳에서는 MailSlot 방식의 통신을 하도록 구현하였고 이와 같이 실행 프로그램에 인자를 전달하고자 할 때 이 방식을 쓸 수 있다. 매우 잘 동작한다.

:)