incoming call interface
-
Friday, January 08, 2010 5:31 PMWhen there is an incoming call, I want my program to run and control interface, shielding the system call management interface. Should be how to do? Whether to change the registry? With the c # can be achieved?
Answers
-
Monday, January 11, 2010 11:51 PM
You would need to check this idea, I don't know if that's applicable: the "Phone - Incoming" window should be the MainWindow associated to the OS Process CPROG.EXE. So you could use Windows functions to retrieve the handle of the MainWindow of the process named "cprog.exe" and then call ShowWindow on it. To be sure about this, you can use Remote Spy. If you need sample P/Invoke code showing how to do it, you can use the same approach I mentioned here for subclassing an application you know only the exe name of: "[...] a possible approach is to enumerate active processes to get the ID of the one you’re interested on, so that you can use System.Diagnostic.Process.MainWindowHandle property to retrieve the window handle you want to subclass. Unfortunately NETCF's System.Diagnostic.Process class doesn’t implement all the methods that would have helped, for example .GetProcesses(): however, you can mix up a “Process” class exposing a .GetProcesses() method with the System.Diagnostic.Process to exploit its .MainWindowHandle. Such custom class is provided as a sample by the following MSDN article: Creating a Microsoft .NET Compact Framework-based Process Manager Application".
Pls allow me also to spend some words around CPROG.EXE and how to "intercept" incoming phone calls. The approach that Zhe mentioned above is the only "supported" one for ISV Application Developers, compared to the approaches available to Windows Mobile's OEMs (=device manufacturers), who can have the "phone UI application" to interact with the underlying RIL Driver that *they* develop and include in *their* OSs. In other words, interfering with the OS Native Phone application (for example by killing\restarting cprog.exe) is not supported for ISV Application Developers, contrarily to Device Manufacturers (OEMs) who actually build their own OS based on the Windows Mobile platform and therefore can develop and include whatever they want on their Operating Systems, as long as they fulfill the “Windows Mobile Logo Test Kit”, so that their OS is certified as “Windows Mobile”. Note that “supported” is different than “technically achievable” – I’ve discussed about this at Support Boundaries for Windows Mobile Programming (Developing Drivers, for example... Or even WiFi Programming) – basically something is “not supported” when the product was not meant for it or has not been tested by the Dev Team to do that. As an example, a thing that the Windows Mobile platform doesn’t test or even consider is to kill CPROG.EXE: once the device is booted, CPROG.EXE executes (unless it's a Windows Mobile Classic) and even when there is out-of-memory condition (so that the Shell starts asking every application to shut down), CPROG.EXE is not terminated. So the current OS design does not expect it to be killed forcefully.
HTH!
Thanks,
~raffaele
http://blogs.msdn.com/raffael
This posting is provided 'as is' with no warranties and confers no rights.- Marked As Answer by ZHE ZHAO Friday, January 15, 2010 4:03 AM
All Replies
-
Monday, January 11, 2010 6:21 AMHi,
This link will be helpful for you to get started
Main idea is to use State and Notifications Broker Base Properties to monitor incoming call event, and remove the system’s notifying window.
Regards,
Zhe Zhao
-
Monday, January 11, 2010 5:51 PM
I have found them.
Guang-Ming Bian write at the post.You can use State and Notification Broker introduced to monitor the incoming phone call and once incoming call comes, find incomming call window with caption("Phone - Incomming") and hide it. Like the code below:
Code Snippet[DllImport("coredll.dll")]
public extern static int FindWindow(string classname, string text);
[DllImport("coredll.dll")]
public extern static void ShowWindow(int h, int op);
private void Form1_Load(object sender, EventArgs e)
{
const string appId = "incomingCallTest";
const string applicationToNotify = @"\Program Files\PhoneIncomingTest\PhoneIncomingTest.exe";
SystemState ss = new SystemState(SystemProperty.PhoneIncomingCall,true);
ss.EnableApplicationLauncher(appId, applicationToNotify);
ss.Changed += new ChangeEventHandler(HandleCall);
}
public void HandleCall(Object obj, ChangeEventArgs arg)
{
int t = FindWindow("", "Phone - Incoming");
ShowWindow(t, 0);
}
But need to hide system windows by name, "Phone - Incoming", if other such as German version Japanese version, it could not.
Are there a other good way?
Thanks. -
Monday, January 11, 2010 11:51 PM
You would need to check this idea, I don't know if that's applicable: the "Phone - Incoming" window should be the MainWindow associated to the OS Process CPROG.EXE. So you could use Windows functions to retrieve the handle of the MainWindow of the process named "cprog.exe" and then call ShowWindow on it. To be sure about this, you can use Remote Spy. If you need sample P/Invoke code showing how to do it, you can use the same approach I mentioned here for subclassing an application you know only the exe name of: "[...] a possible approach is to enumerate active processes to get the ID of the one you’re interested on, so that you can use System.Diagnostic.Process.MainWindowHandle property to retrieve the window handle you want to subclass. Unfortunately NETCF's System.Diagnostic.Process class doesn’t implement all the methods that would have helped, for example .GetProcesses(): however, you can mix up a “Process” class exposing a .GetProcesses() method with the System.Diagnostic.Process to exploit its .MainWindowHandle. Such custom class is provided as a sample by the following MSDN article: Creating a Microsoft .NET Compact Framework-based Process Manager Application".
Pls allow me also to spend some words around CPROG.EXE and how to "intercept" incoming phone calls. The approach that Zhe mentioned above is the only "supported" one for ISV Application Developers, compared to the approaches available to Windows Mobile's OEMs (=device manufacturers), who can have the "phone UI application" to interact with the underlying RIL Driver that *they* develop and include in *their* OSs. In other words, interfering with the OS Native Phone application (for example by killing\restarting cprog.exe) is not supported for ISV Application Developers, contrarily to Device Manufacturers (OEMs) who actually build their own OS based on the Windows Mobile platform and therefore can develop and include whatever they want on their Operating Systems, as long as they fulfill the “Windows Mobile Logo Test Kit”, so that their OS is certified as “Windows Mobile”. Note that “supported” is different than “technically achievable” – I’ve discussed about this at Support Boundaries for Windows Mobile Programming (Developing Drivers, for example... Or even WiFi Programming) – basically something is “not supported” when the product was not meant for it or has not been tested by the Dev Team to do that. As an example, a thing that the Windows Mobile platform doesn’t test or even consider is to kill CPROG.EXE: once the device is booted, CPROG.EXE executes (unless it's a Windows Mobile Classic) and even when there is out-of-memory condition (so that the Shell starts asking every application to shut down), CPROG.EXE is not terminated. So the current OS design does not expect it to be killed forcefully.
HTH!
Thanks,
~raffaele
http://blogs.msdn.com/raffael
This posting is provided 'as is' with no warranties and confers no rights.- Marked As Answer by ZHE ZHAO Friday, January 15, 2010 4:03 AM
-
Monday, March 01, 2010 11:02 AMThanks Raffaele!
I'm trying to use your method to show the incoming call window. I use Remote Spy, and I do find the window, but I don't know what's next :) I'm new to all the handles etc, so perhaps you could post an example or just help a little bit?
What I'm trying to accomplish is to open CPROG.EXE, show the incoming call window and when a key is pressed close it. But if I start CPROG.EXE it only shows the dialer??
Kind regards,
Sander -
Monday, March 01, 2010 2:29 PM
Hi! Once you have the handle of cprog's window, you can invoke windows APIs and, a possible idea, also subclass the window, i.e. intercept all the WM_messages that are sent to it - through Remote Spy you should recognize which messages your application should be interested on. This post is managed subclassing, in any case could help http://blogs.msdn.com/raffael/archive/2008/02/26/subclassing-netcf-applications.aspx.
HTH!
Thanks,
~raffaele
http://blogs.msdn.com/raffael
This posting is provided 'as is' with no warranties and confers no rights. -
Monday, March 01, 2010 5:13 PMThanks for the fast reply!
Well, I've already seen that example, but that's about receiving the messages. The thing is, I want to send messages to the executable :) My application doesn't want to do much, it just wants to show the incoming call window of Windows Mobile.
Also, I don't know how to get the handle when the application is hidden. I used a snippet out of the link you've posted which lists all the processes and iterates through them. However the handle received is zero or does not work !? But when I type the handle manual as seen in Remote Spy, it does work.
So how do I get a good handle and how can I send messages :)
Kind regards,
Sander -
Wednesday, March 03, 2010 10:55 AMEven if hidden, if the window exists you should be able to grab its handle. You may want to adapt the managed code that lists all the windows as I've described at http://blogs.msdn.com/raffael/archive/2009/04/29/findwindowex-on-windows-mobile-not-supported.aspx.
HTH!
Thanks,
~raffaele
http://blogs.msdn.com/raffael
This posting is provided 'as is' with no warranties and confers no rights. -
Sunday, October 10, 2010 12:07 PM
Hi,
This link will be helpful for you to get started
Main idea is to use State and Notifications Broker Base Properties to monitor incoming call event, and remove the system’s notifying window.
Regards,
Zhe Zhao
Is the link invalid? Something error occurs when opening the link.

