none
Inter Process communication help.. RRS feed

  • Question

  • Hi,

    I am newbie. using C++.net 2005 MFC " Windows Mobile 5.0". I want to send or post message to Application ABC through Application IPC1..

    ABC is simple background program with WM_CLOSE method..

    First,I run the ABC program and then i run the IPC1 program ... ABC program is running in the back when i Launch IPC1 program.

    I have tried this .

     

    BOOL CIPC1App::InitInstance()

    {

    SHInitExtraControls();

    SetRegistryKey(_T("Local AppWizard-Generated Applications"));

    m_pMainWnd = &dlg;

    HWND hWndMainWindow = FindWindow(_T("ABC"), NULL);

    if (hWndMainWindow != NULL)

    {

    PostMessage(hWndMainWindow, WM_CLOSE, 0, 0);

    }

    dlg.Create(IDD_IPC1_DIALOG,NULL);

    dlg.ShowWindow(TRUE);

    return FALSE;

    }

     

    but it return NULL handle in FindWindow....  I am totally confused with the   LPCTSTR lpClassName,
      LPCTSTR
    lpWindowName parameters .. 

    I gave application name in the first argument of FindWindow... if i am wrong then what i will give on 1 parameter... and what is window class name all about and from where i get this name ?

    Any example or idea. How i accomplish that task ?

     

    Thanks

    -Salman

    Saturday, May 19, 2007 10:58 AM

Answers

  • Hi Salman,

     

    Try swapping around the order of the parameters within the call to FindWindow i.e.

    Code Snippet
    HWND hWndMainWindow = FindWindow(NULL, _T("ABC"));

     

    As you state the FindWindow function takes two parameters as follows:

    • lpClassName - This is the name of the window class of the window you want to search for (or NULL if you only want to search by window title).
    • lpWindowName - This is the window text (caption) of the window you want to search for

    The window name parameter is fairly straight forward, so what is a window class?

     

    Since you are using MFC this concept is fairly abstracted away from you. Underneath the covers the Win32 GUI APIs has a concept called a window class. All windows of a given class should behave and act in a similiar way. For example an edit control is little more than a child window with a standard window class called "EDIT", and a button is simply a window of window class "BUTTON".

     

    If you create a raw Win32 Smart Device project you will see a function called RegisterWindowClass which fills out a structure and registers a new class of window with the operating system. It's important to note that one of the fields in this structure is a window procedure function pointer. This procedure (which in MFC loosly maps to the various OnXXXX handlers you write) is the common piece of code which responds to all window messages for all windows of the same window class and gives them their distinctive appearnce and behaviour.

     

    If you want to view the class name of a window in an application not developed by you, you can make use of a tool called Remote Spy++. You can find this tool in the start menu on your desktop, look within the Visual Studio Remote Tools folder underneath the main visual Studio 2005 one. With this tool you can connect to any active sync connected device (or emulator) and view all the windows currently active on the device. Within the tree view you will see the current window title and class names for each window.

     

    As i said the MFC framework internally hides some of this window creation logic behind the scenes for you (after all that is one of the reasons to use such a framework in the first place). You could use Remote Spy++ to determine the window class name used by your application, or you could continue to simply use NULL (if the window title is sufficiently unique that you won't get an incorrect match due to another window having the same title).

     

    Hope this helps,

    Christopher Fairbairn

    Saturday, May 19, 2007 11:56 AM
  • Hi Salman

    Once you got the handle of the process by Opening the Process form the Process id, you can use "PostMessage" or "SendMessage" and pass the handle that you got and send the corresponding Window Message to the application.

     

    You can also use CreateMsgQueue to commnunicate between two application.

    Monday, May 21, 2007 8:19 AM
  • Hi Salman,

     

    One trick here (which is used heavily by Microsoft itself in the Windows Mobile operating system) is to create a window in the background process but keep it hidden. This way you can search for it via the FindWindow() API, and communicate with it by sending it messages, but the user can't see it or interact with it.

     

    To make a window totally hidden you have a couple of choices. Perhaps the easiest is to create a window via the CreateWindow API, and just make sure it doesn't include the WS_VISIBLE window style, you could also create a window with a client rect of 0x0pixels.

     

    If you use the Remote WinSpy++ tool I mentioned in a previous posting you will be able to see various windows with titles such as "Listener" or "NotifyWindow", tis is typically the purpose of such windows.

     

    Another thing you may be interested in if you are looking at making a background application with no visible UI, is a service. These are DLLs which run within a system executable called services.exe. The OS provides a standardised API to start and stop them, as well as to communicate with them. The basic theory (with a slight Windows CE bent to it) is documented in the following article on MSDN - http://msdn2.microsoft.com/en-us/library/aa446909.aspx.

     

    Perhaps you could modify your background process to become a service hosted within a DLL? This has an additional advantage that since your background process is a dll hosted within services.exe you background process doesn't count towards the 32 process limit imposed on all devices running Windows CE versions before 6.0 (which for Windows Mobile devices means every currently shipping device, including the new Windows Mobile 6 devices, since WM6 devices actually have the core WinCE 5.0 kernel within them).

     

    Hope it helps,

    Christopher Fairbairn

    Monday, May 21, 2007 8:26 AM

All replies

  • Hi Salman,

     

    Try swapping around the order of the parameters within the call to FindWindow i.e.

    Code Snippet
    HWND hWndMainWindow = FindWindow(NULL, _T("ABC"));

     

    As you state the FindWindow function takes two parameters as follows:

    • lpClassName - This is the name of the window class of the window you want to search for (or NULL if you only want to search by window title).
    • lpWindowName - This is the window text (caption) of the window you want to search for

    The window name parameter is fairly straight forward, so what is a window class?

     

    Since you are using MFC this concept is fairly abstracted away from you. Underneath the covers the Win32 GUI APIs has a concept called a window class. All windows of a given class should behave and act in a similiar way. For example an edit control is little more than a child window with a standard window class called "EDIT", and a button is simply a window of window class "BUTTON".

     

    If you create a raw Win32 Smart Device project you will see a function called RegisterWindowClass which fills out a structure and registers a new class of window with the operating system. It's important to note that one of the fields in this structure is a window procedure function pointer. This procedure (which in MFC loosly maps to the various OnXXXX handlers you write) is the common piece of code which responds to all window messages for all windows of the same window class and gives them their distinctive appearnce and behaviour.

     

    If you want to view the class name of a window in an application not developed by you, you can make use of a tool called Remote Spy++. You can find this tool in the start menu on your desktop, look within the Visual Studio Remote Tools folder underneath the main visual Studio 2005 one. With this tool you can connect to any active sync connected device (or emulator) and view all the windows currently active on the device. Within the tree view you will see the current window title and class names for each window.

     

    As i said the MFC framework internally hides some of this window creation logic behind the scenes for you (after all that is one of the reasons to use such a framework in the first place). You could use Remote Spy++ to determine the window class name used by your application, or you could continue to simply use NULL (if the window title is sufficiently unique that you won't get an incorrect match due to another window having the same title).

     

    Hope this helps,

    Christopher Fairbairn

    Saturday, May 19, 2007 11:56 AM
  • Thanks Christopher,

    I really get great help by your reply. but it is working on dialogue base application.. since they have Window Title . i want to pass message to the Background Application (which has no dialogue) how i achieved my task? how i post message??

    Is there any method to pass messages through Process ID? 

     

    or sending messages to Background Application or dialogue less application ?

     

    Thanks

    -Salman

    Monday, May 21, 2007 7:37 AM
  • Hi Salman

     

    It is possible to post or send message to the application the application (not having the window) that are running in the background. First enumerate the process that are currently running and perform the operation that you want to do on the enumerated processes. Check the link for enumerating the process list( CreateToolHelp32Snapshot).

     

    If know the process id then try this also.

     

    Supply the process id value to dword variable lPorcID.

     

    HANDLE  lHndl = OpenProcess(NULL,false,lProcId);

    if(lHndl)

      TerminateProcess(lProcId,1);

    Monday, May 21, 2007 8:01 AM
  • Thanks Saravanan,

    But i dont want to terminate that process. i want to invoke WM_CLOSE or WM_OK or other events through my IPC1 program. how i will communicate with SimpleDialogue which is a background application...

    I enclosed WM_CLOSE just as example. i want to learn Message Passing in between Background Applications..

     

    Thanks

    -Salman

     

    Monday, May 21, 2007 8:14 AM
  • Hi Salman

    Once you got the handle of the process by Opening the Process form the Process id, you can use "PostMessage" or "SendMessage" and pass the handle that you got and send the corresponding Window Message to the application.

     

    You can also use CreateMsgQueue to commnunicate between two application.

    Monday, May 21, 2007 8:19 AM
  • Hi Salman,

     

    One trick here (which is used heavily by Microsoft itself in the Windows Mobile operating system) is to create a window in the background process but keep it hidden. This way you can search for it via the FindWindow() API, and communicate with it by sending it messages, but the user can't see it or interact with it.

     

    To make a window totally hidden you have a couple of choices. Perhaps the easiest is to create a window via the CreateWindow API, and just make sure it doesn't include the WS_VISIBLE window style, you could also create a window with a client rect of 0x0pixels.

     

    If you use the Remote WinSpy++ tool I mentioned in a previous posting you will be able to see various windows with titles such as "Listener" or "NotifyWindow", tis is typically the purpose of such windows.

     

    Another thing you may be interested in if you are looking at making a background application with no visible UI, is a service. These are DLLs which run within a system executable called services.exe. The OS provides a standardised API to start and stop them, as well as to communicate with them. The basic theory (with a slight Windows CE bent to it) is documented in the following article on MSDN - http://msdn2.microsoft.com/en-us/library/aa446909.aspx.

     

    Perhaps you could modify your background process to become a service hosted within a DLL? This has an additional advantage that since your background process is a dll hosted within services.exe you background process doesn't count towards the 32 process limit imposed on all devices running Windows CE versions before 6.0 (which for Windows Mobile devices means every currently shipping device, including the new Windows Mobile 6 devices, since WM6 devices actually have the core WinCE 5.0 kernel within them).

     

    Hope it helps,

    Christopher Fairbairn

    Monday, May 21, 2007 8:26 AM