Related
Hi there
I'm writing an PocketPC Application which also uses the Phone functions.
But how could I catch an incoming call with number?
I just need to get an event to get the number of the incoming call, to make something like an log entry
Can anyone give me some hints?
lineGetCallInfo(....)
and event LINE_CALLINFO
Thanks for your reply
And how can I catch this event in C# ?
1)init TAPI (search on this forum)
2)in cycle call lineGetMessage
in struct LINEMESSAGE check dwMessageId
3)if dwMessageId == LINE_APPNEWCALL - incoming call
4)if dwMessageId == LINE_CALLINFO - call info changed
call lineGetCallInfo
in struct LINECALLINFO check dwCallerIDFlags
5)if you work with different media modes (voice, datamodem, fax and etc) check dwMediaMode in LINECALLINFO structure
using this, how would i know if the phone is on a call already? would i be concerned with dwMessageId also here and what constant would i be comparing to?
thanks.
Thanks for your help
But because I'm new to the .NET stuff , do you have some sample code on how to implement this ?
source codes from vangelderp:
http://forum.xda-developers.com/download.php?id=3598
about geting caller number:
Code:
LPLINECALLINFO lpCallInfo = NULL;
unsigned size = sizeof(LINECALLINFO);
LPLINECALLINFO tmp;
/*lpCallInfo place right size of struct to dwNeededSize*/
while (tmp = (LPLINECALLINFO)realloc(lpCallInfo, size))
{
lpCallInfo = tmp;
lpCallInfo->dwTotalSize = size;
if (lineGetCallInfo(hCall, lpCallInfo))
{
free(lpCallInfo);
return;
}
if(lpCallInfo->dwNeededSize <= size)
break;
size=a->dwNeededSize;
}
if (!tmp)
{
free(lpCallInfo);
return;
}
/*dwCallerIDOffset is offset in bytes from top of struct*/
if (lpCallInfo->dwCallerIDFlags & LINECALLPARTYID_ADDRESS)
_tcsncpy(number, (LPTSTR)((BYTE*)lpCallInfo + lpCallInfo->dwCallerIDOffset), 256);
/*256 symbols only for example*/
using this, how would i know if the phone is on a call already? would i be concerned with dwMessageId also here and what constant would i be comparing to?
thanks.
you can't
use RIL_GetLineStatus from RIL
Has someone experience about using the TAPI Wrapper with .NET CF2.0 ?
Here it doesn'T work at all :-(
I have a problem in setting controls in a Win32 application.
When I use SendMessage to set a text string in a static control I get error number 120 which translated means: "This function is only valid in Win32 mode."
Here's the background:
I'm using Visual Studio 2005, I've installed the Windows Mobile 5 SDK.
The project was created using the New Project Wizard, with the following settings:
Visual C++/Smart Device
Win32 Smart Device Project
Platform SDK is: Windows Mobile 5.0 Pocket PC SDK
Windows application
I've added a dialog template resource and can bring up a dialog based on that resource. It contains a static control that I can read the text from, but attempting to set the text gives me the above error.
The relevent code (within the WM_INITDIALOG message handler) is:
Code:
char buffer[100];
HWND hCtrl = ::GetDlgItem(hDlg, IDC_TITLE);
LRESULT result = ::SendMessage(hCtrl, WM_GETTEXT, (WPARAM)80, (LPARAM)buffer);
This works, I get the correct text (ie the text I have placed into the static control using the dialog template editor) copied into the buffer. What follows is:
Code:
buffer[0] = 'A'; // Just to set up a different string
result = ::SendMessage(hCtrl, WM_SETTEXT, (WPARAM)0, (LPARAM)buffer);
if (result == 0)
{
LPVOID lpMsgBuf;
DWORD error = ::GetLastError();
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPTSTR)&lpMsgBuf, 0, NULL);
::MessageBox(NULL, (LPCTSTR)lpMsgBuf, (LPCWSTR)"LError", MB_OK | MB_ICONINFORMATION);
::LocalFree(lpMsgBuf);
}
The attempt to set the changed text string fails (ie result == 0), and the last error is 120, which is translated to the error message above.
This works the same in both the Windows Mobile 5 emulator, and if I run it on my Atom.
What does this mean? How could it be anything other than Win32 mode?
Is there a function or something I have to call to put it into Win32 mode?
Or is it a project setting in VS2005 that I haven't been able to find?
I'd very much appreciate any help on this.
Peter
Hi Peter.
The only problem I can see in your code is that you are using char instead of WCHAR. Windows Mobile devices only use UNICODE for API calls.
I don't think it is causing the error, but it is strange that you manage to get the correct text out using it.
The only thing I can think of is using GetWindowText and SetWindowText APIs instead of sending the message directly.
Maybe this will solve your problem.
I also notice that you did not initialize the buffer. The string needs to be null terminated so try initializeing all the elements before putting your 'A' in.
I thought 120 was not supported on this system ERROR_CALL_NOT_IMPLEMENTED.
Guys,
Thanks very much for the suggestions.
As for not initializing the buffer, I think the WM_GETTEXT call does that, all I do with the buffer[0] = 'A' call is to modify a single character that now contains the text that was copied out from the control.
But I take your point about using WCHAR, I'll do that when I get a chance.
And I'll try the Get and SetWindowText calls.
Thanks again.
Ok, How about this then?
The buffer is initialized by the WM_GETTEXT message, and it is set to the correct value (ie the initial contents of the control).
Changing the first character works.
The WM_SETTEXT message fails (result == 0) and the translated error (120) as displayed in the message box is "This function is only valid in Win32 mode."
The SetWindowText also fails with the same last error.
Does anyone know what "Win32 mode" is? I have spent time searching the MSDN and googling it. I've seen some references to it as an error message, but I haven't found an explanation.
Thanks,
Peter
Code:
WCHAR buffer[100];
HWND hCtl = ::GetDlgItem(hDlg, IDC_TITLE);
LRESULT result = ::SendMessage(hCtl, WM_GETTEXT, (WPARAM)80, (LPARAM)buffer);
buffer[0] = WCHAR('A');
//BOOL textResult = ::SetWindowText(hCtl, (LPCWSTR)buffer);
result = ::SendMessage(hCtl, WM_SETTEXT, (WPARAM)0, (LPARAM)buffer);
if (result == 0)
{
WCHAR errorTitle[] = L"LastError";
LPVOID lpMsgBuf;
DWORD error = ::GetLastError();
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPTSTR)&lpMsgBuf, 0, NULL);
::MessageBox(NULL, (LPCTSTR)lpMsgBuf, (LPCWSTR)errorTitle, MB_OK | MB_ICONINFORMATION);
::LocalFree(lpMsgBuf);
}
Ok, there is no apparent reason why your code doesn't work. Like OdeeanRDeathshead said according to MSDN error 120 means 'This function is not supported on this system.', something you definitely should not be getting.
One question: is this code inside a class member function? I am asking because of the '::' in front of every API.
Try removing them and see what happens.
Also, no need to use WCHAR('A'), just write L'A' save your self some typing in the long run.
P.S. In my year and a half of programming for Windows Mobile I never heard of a 'Win32 mode' or a function not working because of it. The error may be elsewhere in your code, some problem with name-spaces perhaps?
Are you running this on an actual device or just the emulator?
Hi levenum,
Thanks for the reply. Where to start?
Firstly I tend to use the scope resolution operator wherever possible. In this case ::SendMessage (for example), is meant to be a clear message to the reader that these functions are not member functions of the class, but instead exist in the global namespace. I have tried removing them and there is no difference.
You also asked if the code was in a class member function. Well, yes. It is a static member function of a specialization of a generic dialog class. Both the about box dialog and this setup dialog specialize this generic dialog class. Each has their own static dialog message processing function.
The code is in the part that handles the WM_INITDIALOG message. This is where I would normally (ie in Win32 on good ol' PC type windows) initialize controls before the dialog box is displayed. I have shown the dialog message function, and it is almost identical to the one for the about box that is generated when you create a Win32 project in the wizard.
One other point is that the GetLastError call and the format call are exactly out of the MSDN. If you look up the FormatMessage function, there is example code to translate the error code returned by GetLastError. That's exactly what I have here, and the message it gives is about not being in Win32 mode. So now I'm curious, how do you arrive at the 'This function is not supported on this system' comment. I looked for error and 120, and the only thing I could find was something about ARM messages "improper line syntax; wrong use of local label".
By the way, the SetWindowText function (commented out) gives exactly the same error code. As you say, surely both of these are allowed on this system.
I also appreciate you comment about not having heard of a Win32 mode.
But you have got me wondering if I can simplify the problem further. I will try the initial small project you get generated from the wizard, and in the about box dialog message processing function I will try to set the text in one of the two static controls on the about box.
Thanks again,
Peter
Code:
// Message handler for the setup dalog.
INT_PTR CALLBACK
DialogSetup::DialogSetupDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_INITDIALOG:
{
// Create a Done button and size it.
SHINITDLGINFO shidi;
shidi.dwMask = SHIDIM_FLAGS;
shidi.dwFlags = SHIDIF_DONEBUTTON | SHIDIF_SIPDOWN | SHIDIF_SIZEDLGFULLSCREEN | SHIDIF_EMPTYMENU;
shidi.hDlg = hDlg;
SHInitDialog(&shidi);
// Set up strings
//LRESULT result = ::SendDlgItemMessage(hDlg, IDC_TITLE, WM_SETTEXT, 0, (LPARAM)"Setup");
WCHAR buffer[100];
HWND hCtl = ::GetDlgItem(hDlg, IDC_TITLE);
LRESULT result = ::SendMessage(hCtl, WM_GETTEXT, (WPARAM)80, (LPARAM)buffer);
buffer[0] = WCHAR('A');
//BOOL textResult = ::SetWindowText(hCtl, (LPCWSTR)buffer);
result = ::SendMessage(hCtl, WM_SETTEXT, (WPARAM)0, (LPARAM)buffer);
if (result == 0)
{
WCHAR errorTitle[] = L"LastError";
LPVOID lpMsgBuf;
DWORD error = ::GetLastError();
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPTSTR)&lpMsgBuf, 0, NULL);
::MessageBox(NULL, (LPCTSTR)lpMsgBuf, (LPCWSTR)errorTitle, MB_OK | MB_ICONINFORMATION);
::LocalFree(lpMsgBuf);
}
}
return (INT_PTR)TRUE;
case WM_COMMAND:
switch (LOWORD(wParam))
{
case IDOK:
case IDCANCEL:
{
EndDialog(hDlg, LOWORD(wParam));
return TRUE;
}
}
break;
case WM_CLOSE:
EndDialog(hDlg, message);
return TRUE;
#ifdef _DEVICE_RESOLUTION_AWARE
case WM_SIZE:
{
DRA::RelayoutDialog
(
GetInstance(),
hDlg,
DRA::GetDisplayMode() != DRA::Portrait ? MAKEINTRESOURCE(IDD_SETUP_WIDE) : MAKEINTRESOURCE(IDD_SETUP)
);
}
break;
#endif
}
return (INT_PTR)FALSE;
}
Hi levenum,
Thanks for the reply. Where to start?
Firstly I tend to use the scope resolution operator wherever possible. In this case ::SendMessage (for example), is meant to be a clear message to the reader that these functions are not member functions of the class, but instead exist in the global namespace. I have tried removing them and there is no difference.
You also asked if the code was in a class member function. Well, yes. It is a static member function of a specialization of a generic dialog class. Both the about box dialog and this setup dialog specialize this generic dialog class. Each has their own static dialog message processing function.
The code is in the part that handles the WM_INITDIALOG message. This is where I would normally (ie in Win32 on good ol' PC type windows) initialize controls before the dialog box is displayed. I have shown the dialog message function, and it is almost identical to the one for the about box that is generated when you create a Win32 project in the wizard.
One other point is that the GetLastError call and the format call are exactly out of the MSDN. If you look up the FormatMessage function, there is example code to translate the error code returned by GetLastError. That's exactly what I have here, and the message it gives is about not being in Win32 mode. So now I'm curious, how do you arrive at the 'This function is not supported on this system' comment. I looked for error and 120, and the only thing I could find was something about ARM messages "improper line syntax; wrong use of local label".
By the way, the SetWindowText function (commented out) gives exactly the same error code. As you say, surely both of these are allowed on this system.
I also appreciate you comment about not having heard of a Win32 mode.
But you have got me wondering if I can simplify the problem further. I will try the initial small project you get generated from the wizard, and in the about box dialog message processing function I will try to set the text in one of the two static controls on the about box.
Thanks again,
Peter
Code:
// Message handler for the setup dalog.
INT_PTR CALLBACK
DialogSetup::DialogSetupDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_INITDIALOG:
{
// Create a Done button and size it.
SHINITDLGINFO shidi;
shidi.dwMask = SHIDIM_FLAGS;
shidi.dwFlags = SHIDIF_DONEBUTTON | SHIDIF_SIPDOWN | SHIDIF_SIZEDLGFULLSCREEN | SHIDIF_EMPTYMENU;
shidi.hDlg = hDlg;
SHInitDialog(&shidi);
// Set up strings
//LRESULT result = ::SendDlgItemMessage(hDlg, IDC_TITLE, WM_SETTEXT, 0, (LPARAM)"Setup");
WCHAR buffer[100];
HWND hCtl = ::GetDlgItem(hDlg, IDC_TITLE);
LRESULT result = ::SendMessage(hCtl, WM_GETTEXT, (WPARAM)80, (LPARAM)buffer);
buffer[0] = WCHAR('A');
//BOOL textResult = ::SetWindowText(hCtl, (LPCWSTR)buffer);
result = ::SendMessage(hCtl, WM_SETTEXT, (WPARAM)0, (LPARAM)buffer);
if (result == 0)
{
WCHAR errorTitle[] = L"LastError";
LPVOID lpMsgBuf;
DWORD error = ::GetLastError();
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPTSTR)&lpMsgBuf, 0, NULL);
::MessageBox(NULL, (LPCTSTR)lpMsgBuf, (LPCWSTR)errorTitle, MB_OK | MB_ICONINFORMATION);
::LocalFree(lpMsgBuf);
}
}
return (INT_PTR)TRUE;
case WM_COMMAND:
switch (LOWORD(wParam))
{
case IDOK:
case IDCANCEL:
{
EndDialog(hDlg, LOWORD(wParam));
return TRUE;
}
}
break;
case WM_CLOSE:
EndDialog(hDlg, message);
return TRUE;
#ifdef _DEVICE_RESOLUTION_AWARE
case WM_SIZE:
{
DRA::RelayoutDialog
(
GetInstance(),
hDlg,
DRA::GetDisplayMode() != DRA::Portrait ? MAKEINTRESOURCE(IDD_SETUP_WIDE) : MAKEINTRESOURCE(IDD_SETUP)
);
}
break;
#endif
}
return (INT_PTR)FALSE;
}
That error message comes from the free evc compilers. In the tool "error lookup" and in the help, it gives that mesage to correspond to that number.
I have just tested everthing you did. My dialog also uses a class with static methods for its routine. I used your exact code in the initial dialog handler and experimented with the origional contents of the controll. I tested on 2002 2003 2005 devices and can't make it fail. The worst i can get to happen is if there is no text to start with, just a square character displays after the A.
the only thing different is that you say two dialogs use that routine, but I am guessing that you are not doing bothe at once at this time.
Guys, thanks again for anything you can give me.
Lets see, I don't have the situation where two dialogs are using the same function. They both use a different message handling function (different name).
As I said in my last post (sorry I seem to have posted it twice), I was going to simplify the example. I've done that and I get the same problem.
I created another project with the same settings I described above, called "TestSetText". I made a change in only one place. In the function called "About", the message handling function for the about box dialog, I have inserted my example code to get and set the text for one of the static controls called IDC_STATIC_2. I have made no other changes to the code. So the modified About function is as below, and I have commented the section I have added:
Code:
// Message handler for about box.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_INITDIALOG:
{
// Create a Done button and size it.
SHINITDLGINFO shidi;
shidi.dwMask = SHIDIM_FLAGS;
shidi.dwFlags = SHIDIF_DONEBUTTON | SHIDIF_SIPDOWN | SHIDIF_SIZEDLGFULLSCREEN | SHIDIF_EMPTYMENU;
shidi.hDlg = hDlg;
SHInitDialog(&shidi);
// Code to check setting text - only change
//LRESULT result = SendDlgItemMessage(hDlg, IDC_STATIC_2, WM_SETTEXT, 0, L"Example");
WCHAR buffer[100];
HWND hCtl = GetDlgItem(hDlg, IDC_STATIC_2);
LRESULT result = SendMessage(hCtl, WM_GETTEXT, (WPARAM)80, (LPARAM)buffer);
MessageBox(NULL, (LPCTSTR)buffer, (LPCWSTR)L"Text from control", MB_OK | MB_ICONINFORMATION);
// Modify the extracted text
buffer[0] = L'A';
//BOOL textResult = SetWindowText(hCtl, (LPCWSTR)buffer);
result = SendMessage(hCtl, WM_SETTEXT, (WPARAM)0, (LPARAM)buffer);
if (result == 0)
{
WCHAR errorTitle[] = L"LastError";
LPVOID lpMsgBuf;
DWORD error = GetLastError();
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPTSTR)&lpMsgBuf, 0, NULL);
MessageBox(NULL, (LPCTSTR)lpMsgBuf, (LPCWSTR)errorTitle, MB_OK | MB_ICONINFORMATION);
LocalFree(lpMsgBuf);
}
// End of my change
}
return (INT_PTR)TRUE;
case WM_COMMAND:
if (LOWORD(wParam) == IDOK)
{
EndDialog(hDlg, LOWORD(wParam));
return TRUE;
}
break;
case WM_CLOSE:
EndDialog(hDlg, message);
return TRUE;
#ifdef _DEVICE_RESOLUTION_AWARE
case WM_SIZE:
{
DRA::RelayoutDialog(
g_hInst,
hDlg,
DRA::GetDisplayMode() != DRA::Portrait ? MAKEINTRESOURCE(IDD_ABOUTBOX_WIDE) : MAKEINTRESOURCE(IDD_ABOUTBOX));
}
break;
#endif
}
return (INT_PTR)FALSE;
}
So now there are no double colons, no second dialog, no base class, nothing else to confuse the issue. When the app starts all I have to do is invoke the Help|About menu.
When the WM_GETTEXT message is complete, buffer contains exactly the text I would have expected "TestSetText Version 1.0", and this is what is displayed in the message box. So in principle the SendMessage function works and the control handle (hCtl) is correct. This leads me to suspect that all necessary controls are created by the time the WM_INITDIALOG message is processed, and SHOULD be a good place to modify the controls prior to displaying the dialog box.
Modifying the first character in the buffer (setting it to 'A') succeeds as I can see in the debugger.
The attempt to send the WM_SETTEXT message fails (ie result == 0) and GetLastError returns 120 again. The code as I have it there translates this to "This function is only valid in Win32 mode." And this is displayed in the next message box.
When you see the about box, the first character in the IDC_STATIC_2 control has not been changed.
I've also tried using the SetWindowText call which returns non zero (a failure), and the same thing happens (GetLastError returns 120).
One final comment is that if you look up in the MSDN the FormatMessage function, it gives you code (that I have copied) to translate the GetLastError into a string. This gives the Win32 mode message above.
On the other hand, I have found the 120 error in the section "System Errors - Numerical Order" and 120 is listed there as "This function is not valid on this platform." which both of you guys have mentioned.
Ok, two different error messages. The Win32 mode error I don't understand. The not valid error is much more understandable, but how could these functions not be valid?
If you have stayed with me this far then you have a lot of patience.
Thanks
Peter
perhaps you could work around this. Define a value to use as your own message like #define MY_SETUP_MESSAGE ...some value.
Then do nothing in the handler for WM_INITDIALOG except post your own setup message. Do all your normal stuff there. If that succeeds then take a closer look at the timing of WM_INITDIALOG, else there is something waky going on.
Hang on a second, you wrote:
I've also tried using the SetWindowText call which returns non zero (a failure), and the same thing happens (GetLastError returns 120).
Click to expand...
Click to collapse
Is that correct or is it a typo? According to MSDN non zero return for SetWindowText means success, not failure.
One thing you should try is calling SetLastError(0) before calling SetWindowText. Last error is no automatically reset in any way, so it is possible that error 120 is a result of a previous function. Although that still wouldn't account for not seeing the change text in the control.
In any case this is strange. I always initialize controls in WM_INITDIALOG handler and it never failed before.
Ah, you're right. Sorry, I screwed that up. I misread the MSDN there and did a GetLastError anyway, which returned 120.
SetWindowText returns a value of 1, which implies success, but it wasn't successful in the sense of setting the text, when you see the about box it is unchanged.
I also did a SetLastError to zero before the call, and did a GetLastError after it (even though the return code said success), and it was zero. So by all accounts (return code and GetLastError) it should have worked but didn't. The about box is unchanged.
I have also SetLastError to zero before the SendMessage to set the text. That returns zero, and I am sure that the MSDN says should be TRUE if the text is set, so an error. Trouble is, GetLastError then gives zero implying that there was no failure. When you see the about box, the text is not changed so it did fail.
I will have to experiment some more. Maybe I can't set text in a static for some reason. Do I need to call InitCommonControls for that or something (which I haven't done)?
I will also have to try setting text in an edit control.
I used the format message and got the same win32 mode stuff now. However, the text was modified to the new value. I think the win32 mode error message is a bug. Put the same code into the emulator and the error returned is invalid handle. At least invalid handle is something more definite. In both cases, emulator and real device, even though the returned value is 0 for WM_SETTEXT, and the error message is there, I do not think there is an error. Have you just tried it without any error checking?
Are you creating the dialog using creatdialog/dialogbox?
Hi OdeeanRDeathshead, thanks for the reply.
I don't think the invalid handle error is right here because I have used the same control window handle (hCtl) a couple of statements before to retrieve the text and that worked. I guess what I haven't checked is whether the control window handle is changed somehow as a result of the first call, but that would be really weird.
You said that even though SendMessage/WM_SETTEXT returned 0, you thought it probably wasn't an error. Well, there is support for that in that when I SetLastError to zero just prior to calling it, and call GetLastError just after, the error code was zero, thus no error. But the reason I think that there WAS an error is that it did not modify the static control. This is what I get if I effectively don't do any error checking.
As for how I am creating the dialog, the only code I have modified from the original project created from the application wizard is in the WM_INITDIALOG section of the About function that I showed you above. The dialog is created in the WndProc message handling function for the main window, part of which is below. If it is the IDM_HELP_ABOUT command, from the menu, it calls DialogBox specifying the dialog message processing function 'About' where my modified code is.
The code below is produced by the application wizard.
Code:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
int wmId, wmEvent;
PAINTSTRUCT ps;
HDC hdc;
static SHACTIVATEINFO s_sai;
switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
[b]case IDM_HELP_ABOUT:
DialogBox(g_hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, About);
break;[/b]
case IDM_OK:
SendMessage (hWnd, WM_CLOSE, 0, 0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
break;
etc
I think I am going to have to experiment some more on the weekend. Try some other controls etc.
By the way I meant to mention that exactly the same thing happens in both the emulator as well as my Atom. So far, in all of the combinations of code, I have not been able to programmatically change the text content of a static control on a dialog.
And I've just noticed that my attempt to highlight (bold) the relevent part of the code above didn't work.
D'oh!
Actually I have just thought of something that may be relevent.
The emulator and SDK that came by default with VisualStudio2005 is WindowsCE 2003. When I first tried my code in the emulator, it worked. I could not only set text in a static control, I was also successfully manipulating a date/time picker in a separate dialog. I did lots of GDI rendering in the main window as well. And this code also worked on a friend's WindowsCE2003 PDA.
Things looked good until I tried it on my Atom which is WindowsMobile 5.
None of the above worked (except the GDI rendering). I thought it may have been a problem with the development environment. So I downloaded the WindowsMobile 5 SDK which includes a WM5 emulator. I thought this is bound to fix the problem, ie generate the code with the WM5 SDK.
All of my problems above are with WM5 project and emulator. And I said I was using this way back in the first post.
OdeeanRDeathshead, I had a quick look at your profile and you seem to have some earlier XDA machines. Are you using Windows Mobile 5?
If the problem does turn out to be Windows Mobile 5 related, then that says something very bad about backwards compatibility for that platform. Could it also be a WM5 bug? Surely not something so fundamental as this?
I use evc++3 for a compiler, mainly because I am the kind of person who thinks - if its not broaken why change. I have an Atom and do use it to run code on. I have all os, ie 2002,2002pe,2003,2003se,2005, so I don't think this problem is with the device. It may be vis studio 2005, but others have said it works OK.
PPC operating systems have a nasty history of backwards compatibility issues. I could not say that this is the issue here, but it is definately one reason I stick to a lowest common denominator approach. Why not just get evc3 or evc4 and give them a try. They are free.
I guess I was hoping to do it with Visual Studio 2005 because that is what I use at work. These days I mainly program in C#/.NET.
I kind of miss the low level stuff that I used to do on windows a long time ago. But I reminisce.
I'm assuming that evc++ is embedded visual c++? It sounds like really good advice, I'll look for it and it sounds like it will fix all my problems. Especially if as you say, it works for WindowsMobile 5. Can you tell me if you are supposed to use the WindowsMobile 5 SDK with it?
So OdeeanRDeathshead and levenum, thanks a lot for your help guys.
Peter
Hi all,
I am using eVC++ 4.0, and i've dynamically created a CListView like this:
Code:
lv.Create(0,_T(""),WS_CHILD|WS_VISIBLE,r,this,5);
but I dont know how to handle the events of this control... any ideas??
Mohammad
To get events from a listview (win32) I normally subclass it. I use the subclassing routine to post a message back to the parent when the user is doing something like tapping on it, then the windows routine can check whats selected etc and act on it. Is subclassing possible in mfc ?( I don't use it).
Thank u
but can anybody post some code??
thnx
Ok, I am a bit lazy to look up code at the moment, but here's something:
Yes, subclassing is possible in MFC. You just derive your class from the basic class provided like this:
Code:
class MyListView : pubic CListView
Then you add message handlers in the normal matter.
EDIT: The following passage is incorrect:
But I think subclassing may not be necessary in you case. List box controls send WM_COMMAND messages with notifications of major events like selection change to the parent window. All you have to do is to create a WM_COMMAND handler in your parent class.
Sorry I was thinking of ListBox not list view when I wrote it.
To manually add message handlers you need to put macros like ON_MESAGE or ON_COMMAND in the DECLARE_MESSAGE_MAP section of the class cpp file. All the detaisl are available on MSDN.
Are you saying that a listview will send the same WM_COMMAND as a list box in mfc? Dose this also happen in win32 made listviews. I have always thought it was a bit too tedious to find out when the user taps an item in the listview.
After reading your post levenum I had a quick look and it says that a WM_NOTIFY gets sent to the parent with a LVN_ITEMCHANGED for example. I had not used the LVN_**** because when I looked at them there was none that seem to deal with selections. I would guess that LVN_ITEMACTIVATE or LVN_ODSTATECHANGED would be usefull for this but then a second tap would not be picked up still leaving me wanting subclassing in many situations to get the users tap.
Ok, I have read what u wrote guys and my problem is almost solved, I used the OnNotify() method to handle messages sent from child controls like this:
Code:
BOOL CTest2Dlg::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
// TODO: Add your specialized code here and/or call the base class
if(wParam ==5 ) //5 is control ID
{
NMHDR *ph =(NMHDR*)lParam;
if(ph->code==NM_CLICK)
MessageBox("Click");
else if(ph->code==HDN_ITEMCLICK)
MessageBox("Item Click");
else
{
CString str;
str.Format("%d",ph->code);
MessageBox(str);
}
}
return CDialog::OnNotify(wParam, lParam, pResult);
}
Now there still a very small prolem: what messages should I handle for 'Selected Item Changed' event ?? I know its easy but I couldnt find it
Regards
mohgdeisat: I am sorry, I made a mistake about WM_COMMAND.
OdeeanRDeathshead is right, I was thinking of a list box not list view.
To make up for this, here is some sample code from a win32 dialog app that uses list view control. I hope it will be of some help:
Code:
//this is from the dialog window function:
case WM_NOTIFY: //handle events:
nmhdr = (LPNMHDR)lParam;
switch (nmhdr->idFrom)
{
case IDC_LEDLIST: //list control ID.
return OnLEDListEvent(hwndDlg, (LPNMLISTVIEW)lParam);
break;
}
break;
BOOL OnLEDListEvent(HWND hwndDlg, LPNMLISTVIEW nmlv)
{
/////
// Handles list view control notification messages
switch (nmlv->hdr.code)
{
case LVN_ITEMCHANGED:
return OnLEDListItemChanged(hwndDlg, nmlv);
break;
}
return 0;
}
BOOL OnLEDListItemChanged(HWND hwndDlg, LPNMLISTVIEW nmlv)
{
if (ListView_GetSelectionMark(nmlv->hdr.hwndFrom) != nmlv->iItem) return 0;
/* do what you need here */
return 0;
}
Don't mind the fact that I used 3 different functions. This is part of a bigger program and I am trying to keep things well organized without resorting to classes.
As I understand it, LVN_ITEMCHANGE is received for different reasons so I try to handle only the one coming from selected item. LVN_ITEMACTIVATE is only sent when you double click the item so if you just want to catch selection change you need to use LVN_ITEMCHANGE.
Once again, sorry for confusing you before.
thanx pals, good job!!!
I think my problem is now solved with ur help :wink:
Mohammad
Ok guys, I said that my problem was solved, yet, another problem arises...
When the list view is in the report mode, how can I determine when a header button is clicked, and determine which one was clicked???????
thanx in advance
To identify a header column click, you need to handle the WM_NOTIFY/HDN_ITEMCLICK message. Normally this message will be received by the header's parent control (i.e. the listview) -- some frameworks may redirect the message to the header control itself. I haven't worked with MFC in 10 years so I can't really if it reflects notification messages back to the control.
If you're trying to implement column sort, do yourself a favor and check out the Windows Template Library (WTL) at sourceforge.net. It's a set of C++ template classes that provide a thin yet useful wrapper around the standard Windows UI components. One of the classes is a sortable listview control. I've been using WTL with big Windows for more than 5 years -- you couldn't pay me to go back to MFC.
hi,
I have seen the WTL library and it seems very useful and time-saver, but I have a couple of questions about it:
1. can WTL 8.0 be installed with VC++ 6.0, specifically the appwizard stuff??how?? I see only javascript files of vc7.0 and 7.1 and 8.0!!
2. is there a good documentation about those classes??
Mohammad
I don't know about WTL 8; I'm still using WTL 7.5 with VS .Net 2003 for all my Win32 development. My guess is that it wouldn't work too well, as WTL is based on ATL, which has substantially changed between VC 6 and 7.
Good references for WTL include www.codeproject.com/wtl, and the WTL group over at Yahoo groups (reflected at www.gmane.org).
Ok, when I'm in my office I have poor signal issues that drain my battery and miss calls. If I switch to Roaming Only in my phone settings, then everything is just peachy. Problem is, its a lot of menus to click through every single time I come in to my office (Start, settings, phone, services, roaming, get settings, roaming only).
And then when I'm leaving, I want to turn the romaing settings back to automatic, once again its a lot of clicking.
I would imagine it would not be too difficult to write an app that could toggle that setting. Then it could be one click, or someone could even map the app to a hardware button for the ultimate ease of use.
I'm sure there are others who can see how useful such an app would be. Many of us do something like this all the time.
So, what do you think? Anyone willing to help develop this?
Sounds like a do-able program that would be very useful even for people not in your situation. Of course, I don't know how to, I'm just endorsing this idea.
In for this
GREAT!
Now, who can actually help figuring out how to code this? Can that sort of data even be accessed from standard APIs?
MortScript
Ok folks, until I have the time to find out what actually goes on behind the scenes when roaming settings are changed, I think our best bet is to write a script of keypresses/mouseclicks using mortscript.
Mortscript, in case you didn't know, is a simple batch process program, which lets you assign a series of commands to a script, sort of like a macro.
This will essentially be a script to go through the menus and click through options to do what we would do by hand. It will speed things up a bit, but it won't be as simple as a standalone app.
playing with mortscript now, I'll keep you guys posted.
EDIT: Anyone who wants to take a crack at this as well, by all means, mortscript is free! I'm just learning how to use it now, but if anyone has any experience with it, hit me up with suggestions! Or better yet, write a script and show me how it works!
Can anyone tell me what registry changes are made when you switch from roaming to automatic?
I can't seem to compare registry backups taken with PHM RegEdit (some propietary format, and no export to text option!)
Mortscript to the rescue....
This is still not the most ideal solution, but it works for me.
I wrote two Mortscript scripts that simulate the key taps automatically. The downside to this is that you can't toggle it on/off, you need to run one program to force roam, and another one to put it back to automatic.
USE THESE AT YOUR OWN RISK!
If you have any bugs/questions/comments, let me know.
Requirements
MortScript:
You need to install the mortscript interpreter first.
http://www.sto-helit.de/downloads/mortscript/MortScript-4.0.zip
The zip file attached below contains two .mscr files:
Roam
Roam-NO
Pretty self explanatory what does what. You can rename them if you want, this just works for me.
Dishe said:
I wrote two Mortscript scripts that simulate the key taps automatically. The downside to this is that you can't toggle it on/off, you need to run one program to force roam, and another one to put it back to automatic.
Click to expand...
Click to collapse
If you wanted to, you could write a temp file or reg key to check if the setting is on or off. In fact, the file wouldn't even need any data in it, you could just check for it's existence. That way you only need one script. Hope that helps you out.
I havent been able to find (or pull) the ril.dll file from a Mogul Wm6 installation, but once you have that file, you should be able to dump the exports and use the RIL_* functions by ordinal. This has been done on GSM phones.
I haven't had time yet, but I believe someone has dumped the files from the newest update rom.
Dishe,
I took your script and applied my suggestion to it. I also wrapped it up in a standalone package, so if anyone else wants to run it, they won't need MortScript installed as the exe is in here. If you already have MortScript installed, you can just run the .mscr file instead of the .exe of the same name.
What it will do is run the prog, then check for the existence of the file "roam" in the script path. If it's not there, it will run your roam function and then create the file. If it already exists (meaning you turned on roaming only), then it run your function to turn off roaming and delete the temp file. Hope it helps you out.
EDIT: If for some reason the key presses do the wrong thing, you can just set your phone back to automatic and delete the "roam" file in the script path if it's there, then you're back in business.
EDIT2: Added a longer wait time (5 secs) for the Comm Manager, should allow it to work with more graphic intensive Comm Managers (like the Kaiser 10-button, tested).
Vinny75 said:
I havent been able to find (or pull) the ril.dll file from a Mogul Wm6 installation, but once you have that file, you should be able to dump the exports and use the RIL_* functions by ordinal. This has been done on GSM phones.
I haven't had time yet, but I believe someone has dumped the files from the newest update rom.
Click to expand...
Click to collapse
I know, qouting myself, but.. you don't need the ordinal, you can get the function by name from the dll, so far I am able to use RIL_Initialize and RIL_GetRoamingMode to call my pfResultCallback, but the value I am getting in reutrn isn't making sense, so have to figure that out. I am using a modified tstril util. I can post the changes if anyone wants to take a look.
Got the following for RIL_GetRoaming Mode
Mode Value
Sprint Only 0x00000001
Automatic 0x000000FF
Roaming Only 0x000000FE
Now using RIL_SetRoamingMode, I can set the Sprint Only mode, the other two throw a 0x80004005 HRESULT, I can use 0x00000002 and 0x0000003 (constants defined if you search the internet), and they don't throw an error, but they dont actually change any settings...
You can get tstril from here:
http://wiki.xda-developers.com/index.php?pagename=RIL
Expanded ril.h (not sure how accurate):
http://www.xs4all.nl/~itsme/projects/xda/ril/ril.h
Replace the DoRIL function in tstril.cpp with this code to test:
Code:
typedef HRESULT (*pfnRIL_Initialize)(DWORD, RILRESULTCALLBACK, RILNOTIFYCALLBACK, DWORD, DWORD, HRIL*);
typedef HRESULT (*pfnRIL_GetRoamingMode)(HRIL);
typedef HRESULT (*pfnRIL_SetRoamingMode)(HRIL, DWORD);
//HRIL g_hRIL;
HINSTANCE g_hDLL;
HRESULT g_hResult;
DWORD
DoRIL(LPVOID lpvoid)
{
HRESULT result;
DWORD dwNotificationClasses = 0xFF0000;
LRESULT lresult;
TCHAR szString[256];
SendMessage(g_hwndEdit, LB_RESETCONTENT, 0, 0);
lresult = SendMessage(g_hwndEdit, LB_GETHORIZONTALEXTENT, 0, 0);
SendMessage(g_hwndEdit, LB_SETHORIZONTALEXTENT, 1000, 0);
//result = RIL_Initialize(1, ResultCallback, NotifyCallback,
// dwNotificationClasses, g_dwParam, &g_hRil);
//wsprintf(szString, L"RIL Handle: %08X, result %08X", g_hRil, result);
//SendMessage(g_hwndEdit, LB_ADDSTRING, 0, (LPARAM) szString);
g_hRil = NULL;
g_hDLL = LoadLibrary(L"ril.dll");
//HRESULT hResult = 0;
if (g_hDLL != NULL)
{
pfnRIL_Initialize lpfnRIL_Initialize = (pfnRIL_Initialize)GetProcAddress(g_hDLL, L"RIL_Initialize");
if (lpfnRIL_Initialize)
{
result = (lpfnRIL_Initialize)(1, ResultCallback, NULL /*NotifyCallback*/, 0 /*dwNotificationClasses*/, 0 /*g_dwParam*/, &g_hRil);
if (result == S_OK)
{
wsprintf(szString, L"Initialize RIL Handle: %08X, result %08X", g_hRil, result);
SendMessage(g_hwndEdit, LB_ADDSTRING, 0, (LPARAM) szString);
pfnRIL_GetRoamingMode lpfnRIL_GetRoamingMode = (pfnRIL_GetRoamingMode)GetProcAddress(g_hDLL, L"RIL_GetRoamingMode");
if (lpfnRIL_GetRoamingMode)
{
g_hResult = (lpfnRIL_GetRoamingMode)(g_hRil);
wsprintf(szString, L"GetRoamingMode RIL Handle: %08X, g_hResult %08X", g_hRil, g_hResult);
SendMessage(g_hwndEdit, LB_ADDSTRING, 0, (LPARAM) szString);
}
//pfnRIL_SetRoamingMode lpfnRIL_SetRoamingMode = (pfnRIL_SetRoamingMode)GetProcAddress(g_hDLL, L"RIL_SetRoamingMode");
//if (lpfnRIL_SetRoamingMode)
//{
// g_hResult = (lpfnRIL_SetRoamingMode)(g_hRil, 254);
// wsprintf(szString, L"SetRoamingMode RIL Handle: %08X, g_hResult %08X", g_hRil, g_hResult);
// SendMessage(g_hwndEdit, LB_ADDSTRING, 0, (LPARAM) szString);
//}
}
}
//FreeLibrary(g_hDLL);
}
// while(1) {
// Sleep(100);
//// wsprintf(szString, L"%s",L"...");
//// SendMessage(g_hwndEdit, LB_ADDSTRING, 0, (LPARAM) szString);
// }
return 0;
}
Thanks for the work on those Mort Scripts!
Thank you!
wow, I haven't checked this thread in a while...
Vinny75, I haven't had time to play with this, but it looks like you've been making some progress... how far have you gotten with this?
The following values you should work for the second parameter of the RIL_GetRoamingMode and RIL_SetRoamingMode functions... they appeared to work on my phone
Mode RIL_GetRoamingMode RIL_SetRoamingMode
Sprint Only 0x00000001 0x00000001
Automatic 0x000000FF 0x00000004
Roaming Only 0x000000FE 0x00000005
I found the RIL_SetRoamingMode value in the following Registry Key
[HKEY_LOCAL_MACHINE\SOFTWARE\OEM\PhoneSetting\NetworkService]
Vinny75 said:
The following values you should work for the second parameter of the RIL_GetRoamingMode and RIL_SetRoamingMode functions... they appeared to work on my phone
Mode RIL_GetRoamingMode RIL_SetRoamingMode
Sprint Only 0x00000001 0x00000001
Automatic 0x000000FF 0x00000004
Roaming Only 0x000000FE 0x00000005
I found the RIL_SetRoamingMode value in the following Registry Key
[HKEY_LOCAL_MACHINE\SOFTWARE\OEM\PhoneSetting\NetworkService]
Click to expand...
Click to collapse
So would editing the registry be sufficient to change the roaming mode of the phone?
Did you compile an app to do this?
slightly off topic, but i think vinny75 might know the answer. id like to modify my alltel-based rom to give sprint only, automatic, roaming only options (alltel gives home only and automatic.) is ril.dll all that is needed from the sprint rom?
Dishe said:
So would editing the registry be sufficient to change the roaming mode of the phone?
Did you compile an app to do this?
Click to expand...
Click to collapse
I just compiled a quick and dirty app to test the values... the source is in my previous posts
I am trying to access some control panel applets from
my application. This works fine for the most applets.
I use the ctlpnl.exe process to display the applets like:
CreateProcess(_T("ctlpnl.exe"), _T("cplmain.cpl,27,0"), NULL, NULL, FALSE, 0, NULL, NULL, NULL, &pi);
For some reason I cannot display the applet for USB to PC connection (ID 27 in WM5, 28 in WM6).
In WM6 I have the same problem with the encryption applet (ID 27). All other applets work. The applet is displayed for 1 second, I can see
the title in the window and then it disappears.
Has anybody made the same experiences? Is there a workaround for this?
Is this a bug in ctlpnl.exe or in WM5/6?
Thanks for any help.
Houser
Try calling it independent of ctlpnl.exe:
Do a LoadLibrary on the .cpl file
Call GetProcAddress to get a pointer to the CPlApplet function
Call CPlApplet with msg == CPL_INIT
Call CPlApplet with msg == CPL_GETCOUNT to get the # of applets supported by the .cpl file
For each applet above (i = 0 to CPL_GETCOUNT - 1), call CPlApplet with msg == CPL_NEWINQUIRE, taking note of the lData value returned.
For the applet you want to launch, call CPlApplet with msg == CPL_DBLCLK, lParam1 == the applet #, lParam2 == the lData value from the previous step.
When you're done, call CPlApplet with msg == CPL_STOP.
I've done this in big Windows, but never on CE -- my read of the MSDN doc suggests it should work on WM 5/6.
Have already tried it this way but not with lData value when
calling CPL_DBLCLK. But the problem is still there. When I want to access
the cplmain.cpl applet with ID 27 (USB to PC connection) it does not work.
The other IDs (<27) work perfectly.
I do not know why! Arghhh!
Houser
Nobody has encounter same problems with CPL applets?
Houser
did you ever figure this out?
I am having same issues
Houser said:
I am trying to access some control panel applets from
my application. This works fine for the most applets.
I use the ctlpnl.exe process to display the applets like:
CreateProcess(_T("ctlpnl.exe"), _T("cplmain.cpl,27,0"), NULL, NULL, FALSE, 0, NULL, NULL, NULL, &pi);
For some reason I cannot display the applet for USB to PC connection (ID 27 in WM5, 28 in WM6).
In WM6 I have the same problem with the encryption applet (ID 27). All other applets work. The applet is displayed for 1 second, I can see
the title in the window and then it disappears.
Has anybody made the same experiences? Is there a workaround for this?
Is this a bug in ctlpnl.exe or in WM5/6?
Thanks for any help.
Houser
Click to expand...
Click to collapse