I am looking for some help to assist in reading and writing values to the registry from a program on WM5. I am writing the program in either VB or C# using Visual Studio 2005 as that is what i have experience in.
Can anyone offer any assistance to assist me as my reseach has had me banging my head on the wall all day.
Thnx.
GF
something like this works on a pc in C#
should be 100% the same on a pda
most .net stuff is the same apart from advanced controls
which are excluded in compact framework
string myValue;
RegistryKey pRegKey = Registry.LocalMachine;
pRegKey = pRegKey.OpenSubKey("Software\\Some Program");
Object val=null;
Object val2=null;
if(pRegKey!=null)val = pRegKey.GetValue("Some Key");
if(val==null)
{
RegistryKey key = Registry.LocalMachine.OpenSubKey("Some Key", true);
RegistryKey newkey = key.CreateSubKey("Some Value");
newkey.SetValue("Some Value", "String");
}
else myValue=val.ToString();
If you are using .NET then have a look at the OpenNETCF.Win32.Registry class available from http://www.opennetcf.org which is open source and freely available.
In my opinion .NET is too slow on the PPC. I am just getting used to writing for the PPC and WM5 but I am using eVC4 which being C++ is much faster. I am also writing a RegEdit utility as my first project. I am however a Software Engineer and am used to C++ and also C# and VB6.
Type or Namespace RegistryKey could not be found
Thnx for the help to date. I now get the above error once i have imported the code provided. The help refers to the following declaration:
[ComVisibleAttribute(true)]
public sealed class RegistryKey : MarshalByRefObject, IDisposable
But i am unsure of where to place this within the code to adequately declare the RegistryKey.
I have looked at http://www.opennetcf.org but all the code is for older versions of the VS. One would think there would be an easy solution in the world for this type of thing.
GF
Once you have built the DLL from the OpenNETCF you should then have a OpenNETCF.Win32.Registry.DLL which is a .NET DLL. Then add a reference to this DLL in your project:
Project->AddReference - click on the Browse tab and browse for the said DLL. This will then be added to your project for you to use. In the class where you need to access the classes in the DLL add a using directive for
Code:
[color=blue]using[/color] OpenNETCF.Win32
;
You don't need to use InterOp services as it isn't a COM DLL.
HTH
Sorry the embedding didn't work too well the code to add for a using directive is:
Code:
using OpenNETCF.Win32;
Incorrect reference appeared to be the issue
I have managed to get it running, i think it was a problem with using OpenNETCF.Win32.RegsitryKey, where the default VS uses is Microsoft.Win32.RegistryKey
Thnx for everyones help.
GF
Just download the WM5 SDK for Pocket PC or SmartPhone, Registry editing is then possible using the .NET CF V2
ie:
Code:
Dim RegKey As RegistryKey = Registry.LocalMachine.CreateSubKey("System\StorageManager\FATFS")
Dim RegValue As String = RegKey.GetValue("CacheSize", Nothing)
RegKey.SetValue("ReplStoreCacheSize", GeneralSystemPerformanceCmb.Text, RegistryValueKind.DWord)
Yes of course it is possible. But .NET apps on a PPC is JUST TOOOOO SLOOOOOWWWW. In my opinion there is no chois=ce but to go with C++ until the PPC processors get much faster, which .NET expects.
Related
Hi all,
I am developing applications in C# using Visual Studio 2003.
While my need to create some specific applications, it seems some applications seems virtually impossible to develop using C#.
For instance, I cannot create a SIP (soft-input panel) using C#, and I haven't found a way to develop a today plugin using C#. These applications seems only to be developed using C++.
I know C# is a managed code, as opposed to C++ which isn't by default.
Are the differences between C# and C++ applications -- managed vs. unmanaged code -- the reason I cannot develop a today plugin or SIP, or is there a way I can use C# to achieve this?
I'm using C# since it somewhat resembles the Java language I'm familiar with, and learning C++ would take a while.
Any thoughts and help would be much appreciated!
With kind regards
the syntax is not all that different between java c# and c++ even even ansi c
suppose some difference is what platform you would be programming to
maybe .net which i asume most c# programmers use cant make todayplugins
not sure
you can program .net from c++ aswell if you like or you could program win stk directly or miniMFC
a language is just syntax and speed difference in some cases
how much learning is needed is all about the platform you are developing to
Rudegar said:
the syntax is not all that different between java c# and c++ even even ansi c
suppose some difference is what platform you would be programming to
maybe .net which i asume most c# programmers use cant make todayplugins
not sure
you can program .net from c++ aswell if you like or you could program win stk directly or miniMFC
a language is just syntax and speed difference in some cases
how much learning is needed is all about the platform you are developing to
Click to expand...
Click to collapse
Well, applications created with C# must use the .NET Compact Framework if I understand correctly, and since C# (or .NET) applications require the use of a Common Language Runtime, I can image some applications simply cannot be developed.
BTW, the platform I'm targeting to is my much beloved MDA-II
What I'd like to know is, is it possible to create a Today Plugin or a SIP using C#? Or should I switch to C++?
yes i know you mean xda2 but i ment platform as in .net or mfc or pure win stk
not sure if it's possible to make today stuff and other shell stuff from .net
but what i'm trying to say is that you can make .net from c++ aswell and there the difference between c# and c++ are not all that great
if you have to do pure win stk it's a whole other ball game as in how much they are the same
you could ask zendrui the maker of phonezenprofile he's programming in the pure stk and he prob knows if you can assess those today and shell stuff from anywhere else
Ok, thanks for the tip, I will ask him
Sorry but I never looked on the c# as all the applications developped with .net for PocketPC are slower and as I well know c++
So I don't know if it is possible to create a today plugin or access SIP with c# sorry ...
But if you know a little c++ you can get many examples how to create easily a today plugin and for sure access SIP is really really easy with c++ but I suppose that it should be easy to with c# ...
Link to SIP in C#
This might help you out. I just googled for "pocketpc sip c#".
http://www.c-sharpcorner.com/Code/2002/May/SIPOnPocketPC.asp
D.
Hmm that article just gives you information about showing the SIP from your C# app.
I have a feeling, it's going to be easiest to write a SIP in C++, mainly because you're implementing COM interfaces, but also because it's so fiddly and the only examples I've ever seen are in C++.
Best one I've seen is here (also covers today screen items):
http://www.woodslane.com.au/net/titles/samp0735614431.html
.NET CF
A more general question. I have just started looking at using C# (I too am a Java developer) and Visual Studio .NET 2003 to develop apps for the Pocket PC. Help & samples in VS.NET are rather sketchy, and info on MSDN websites is very scattered. What are some good resources to get started? Any books recommended? Any good web resources?
What about MFC?? Can we include MFC on a today plugin DLL?
Because at least CString would sure come handy!! :?
Hello everybody!
I recently went through a learning experience writing a today plug-in and found out there's nothing to it. Basically it’s a dll that needs to export 2 (1 if no options) functions and create a simple window.
You can certainly use MFC, and MSDN has an article on how to create a today plug-in using .NET: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/TodayScrn.asp
As for sip, that is more complicated, sorry I can't help you there.
I tried the c# today pluggin that microsoft made to try and show their language is usefull. It needed two seperate projects, one in vis studio 2003 and one in evc. i got it to work but it was way too complicated. As levenum said, its not that hard in c++. The responsiveness of their example was very slow compared to native ones. The up side was that it created a today item that lets you display data like pie. I did not experiment other than to modify the background colour to see if it worked.
I think the compact framework is a bit too compact. The features don't help enough with device specific programming, but its good for a lot of other stuff like gui's.
Is there any other way to creat today plugin application instead of using C++ and .net host. Is .net 2.0 support it?
Is there any other way to creat today plugin application instead of using C++ and .net host. Is .net 2.0 support it?
I think this topic is pretty much dead, but the answer is that C# does not support exported DLL functions. Since Today plugins and new SIPs require libraries with exported functions, it's not possible to write either entirely in C#. You have to at least have the C library to export the functions, and that's why the MS article goes about it that way.
This class will show/hide the sip in C#:
Code:
public class Sip
{
[System.Runtime.InteropServices.DllImport("coredll.dll")]
private static extern int SipShowIM(SIPStatus i);
private enum SIPStatus
{
SIPF_OFF = 0,
SIPF_ON
};
/// <summary>
/// Show the SIP.
/// </summary>
public static void Show()
{
SipShowIM(SIPStatus.SIPF_ON);
}
/// <summary>
/// Hide the SIP.
/// </summary>
public static void Hide()
{
SipShowIM(SIPStatus.SIPF_OFF);
}
}
I'm trying to work out how to access the a bluetooth serial port for a GPS reciever and cant seem to find any reliable resources.
The device is an XDAIIi with WM2003
I have some Java Knowledge, but not much J2ME.
I also have very limited C# Knowledge and have MS Visual Studio .NET 1.1
I need to simply find a way of getting a string of NMEA GPS (or any!) data from the device via the allready connected serial port.
I would really appreciate some help! I'm not really sure where to start! This was supposed to be a small part of a larger project for my Uni Degree project, but has been giving me a headache for ages!
Any help much appreciated!!!!!
Thanks
Matt
Worked it out in the end
Upgraded to MS Visual Studio 2005 and used its updated port support
Code:
using System.IO.Ports;
public SerialPort port = new SerialPort();
port.PortName = COMListBox.SelectedItem as string;
port.Parity = Parity.None;
port.BaudRate = 4800;
port.StopBits = StopBits.One;
port.DataBits = 8;
try
{
port.Open();
}
~...some looping method
{
byte[] byte_data = new byte[256];
byte_data = port.read();
}
I've done some searching, and I know Windows CE uses Win32, which I know to an extent. I was curious if there are any good free resources for learning WinCE-Win32, or if I should simply use my existing books for MFC/Win32. Microsoft's site kinda sketchy, and MSDN not being very useful. I did get Microsoft Embedded Visual C++ working and compiled a test app which worked on my MDA and on the emulator.
i would just start coding
miniMFC and compact .net framework is soo close it's only
some controls and options you dont have
ortherwise it's the same thing
learning by doing and having ones fingers down and dirty
into the code is where you learn the most
Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.
levenum said:
Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.
Click to expand...
Click to collapse
I knew about how everything was Unicode. Is there an easy way to create unicode strings? I remember there was something in MFC macro like TEXT() that did something like that, but the specifics are missing. I remember there was a knowledge base article on this, but I can't find it.
Also, what's the difference between the Ext version and the non-ext versions of an app?
EDIT: Unless I'm mistaken, I just need to put my strings in _T("*string*")
Yes, you're right, this is how you write strings in your code:
Code:
WCHAR uniStr[] = L"Unicode string";
or if you are using MFC:
Code:
CString uniStr = _T("Unicode string");
and if you have a ASCII string you want converted to UNICODE
use mbstowcs function. (CString class has a built in conversion)
As for the 'ext' API's they just give you more parameters to better control the result of whatever they are doing. In desktop windows if you didn't want to call a function with 10 parameters you usually had a simpler version of it where some things were default.
Example:
Code:
BOOL TextOut(
HDC hdc, // handle to DC
int nXStart, // x-coordinate of starting position
int nYStart, // y-coordinate of starting position
LPCTSTR lpString, // character string
int cbString // number of characters
); //5 parameters
BOOL ExtTextOut(
HDC hdc, // handle to DC
int X, // x-coordinate of reference point
int Y, // y-coordinate of reference point
UINT fuOptions, // text-output options
CONST RECT *lprc, // optional dimensions
LPCTSTR lpString, // string
UINT cbCount, // number of characters in string
CONST INT *lpDx // array of spacing values
); // 8 parameters
what would be your suggestion for a newbie to learn programming for PPC?
I'm beggining to have interest in doing this but have absolutely no idea where to start.
thanks for any advise.
For complete newbies, I wrote this post a while back:
http://forum.xda-developers.com/viewtopic.php?p=209136#209136
V
Hi Guys,
I'm going through the forum, I'm new to embedded developement, I've been able to do my first MessageBox("Hello World") in C using VS2005.
I want to understand how all this works, like :
- Accessing any "mass storage" device ? (the root FS ?, /, c:\, whatevername )
- Dumping the whole registry + values.
- Logging Process and activity even while "device locked" (new process, etc..)
And having more knownledge about the internals and devices, booting etc..
I'm kind of lost and my embedded knowledge is very thin..
The PPC i have is running WM5 on QTEK9100 (SPVM3000)..
Any pointers, posts, sources, small explication are more than welcome...
Hope you can help,
Regards,
r.
Welcome!
Wow those sure are some heavy requests for someone who is just starting.
How much experience do you have with C and Win32 APIs?
To start you off here is an excellent site for Windows Mobile programming tips and tricks:
www.pocketpcdn.com
Couple more pointers:
Device root is "\", no drives (SD cards mounted as folders) kind of like Linux.
All path are absolute - no ".\" or ".."
You can use standard C or Win32 functions for file operations.
Registry functions are also same as Desktop windows except you have to use the "Ex" version of of the function.
Example:
RegOpenKey - not implemented, use RegOpenKeyEx.
For process lists etc, google for ToolHelp32.
Thanks,
I'm at ease w/ ANSI C, have some familiarity w/ Win32 APIs,
but as far as I'm seeing I'm trying to code on Win32 Intel First,
then i try to "port" it to PocketPC Mobile, sometime it works
sometime functions doesn't even exists... MSDN doesn't seems very consistent over Win32 vs WM, but as I'm new I guess i'm missing a lot..
WinMain() prototype changes according to your target...otherwise
VS2005 yell about Overloading WinMain, It is VERY annnoying..anyway
Thanks for the links and the *Ex trick, I'll try to get deeper with this.
I have a strange problem trying to do my Own MessageBoxPrintf:
int MessageBoxPrintf(int, const char * title, const char * fmt, ...)
{
va_list ap;
char * buffer = NULL;
/* formatting and fixed size yes...*/
buffer = (char *) malloc (1024 * sizeof(char));
if (!buffer)
return -1;
memset(buffer, 0, 1024);
va_start(ap, fmt);
vsprintf(buffer, fmt, ap);
va_end(ap);
MessageBox(NULL, (LPCWSTR)buffer, (LPCWSTR)title, type);
return 0;
}
It does compile, but it display craps, since there is no stderr,stdout,stdin and
that I'm mostly coding on Win32/VMware, I don't know how to debug on my PPC (no USB connection), and I have no idea what's wrong.. it might be obvious, but it's late..
As I don't know what LPCWSTR stand for, I assumed char * and it did work on Win32 (XP) without hassle (except LPCWSTR types which are wrong for Win32 Target), so why it doesn't on WM5... is a mystery for me now..
Hope to be on speed ASAP to be able to release some stuff..
Thanks for your help,
Cheers,
r.
all WinAPI function on Pocket PC works with Unicode strings. So you have to convert from ANSI to Unicode.
ok, does the TEXT() macros convert to Unicode string, it seems not.
How to convert from ANSI to Unicode ?
you can work directly with wchar_t or use tchar that can be ansi or unicode, otherwise look for MultiByteToWideChar or CString object _T and TEXT Macro aren't for converting ansi but they makes unicode prefix strings... for example MessageBox(hWnd,_T("Hello World"),_T("my messagebox"),MB_OK);
I hope this help and don't forget MSDN have all replies
have fun,
Guybrush
ok it works! thanks!
just another question, how to dump the "disk" or how those devices are booting ROM?/Flash?
Currently I'm copying all the files from / to the SD card mount point is there anything else?
again thanks for your help.
++
r.
I'm currently doing some programs myself with the free MS embedded VC++.. and I'm finding it comfortable to do a simple dialog-based programs for PPC. I think I can have most of the background code going, and I've just got the GUI .. alright.
Now the question, how do I do a copy/paste to/from clipboard? I had most of the stuff done using the included MFC Wizard. I can get and send data to/from an EditBox (TextBox, whatever you call it). However, the click-hold thing on PPC doesn't seems to work on my EditBox, and hence I'm thinking what's needed to enable a simple Copy/Paste on an EditBox.
Currently, I'm using the simple
Code:
m_editBox = _T("the message I want to show");
UpdateData(FALSE); //send it to the EditBox
Any guide from here would be appreciated. However, I'm thinking there may not be an easy way to do that, hence I've also tried adding a 'Copy' and 'Paste' button to do the job, but I've tried things like
Code:
SetClipboardData(x, x)
GetClipboardData(x)
None works.
I have also tried
Code:
COleDataObject DataObject;
and with the handle etc etc .. but I can't seems to find this COleDataObject , is that in some other environment (e.g. not PPC env)?
Help
Fast solution:
http://www.pocketpcdn.com/articles/sip.html
(this shows/hides sip on get/lost focus in edit controls and add the context menu too)
and this is a simple example how to copy datas into clipboard
if(OpenClipboard(NULL))
{
EmptyClipboard();
HLOCAL clipbuffer = LocalAlloc(0, 100);
wcscpy((WCHAR*) clipbuffer, (WCHAR*) (vtNumber.bstrVal));
SetClipboardData(CF_UNICODETEXT, clipbuffer);
CloseClipboard();
free(szMsg);
LocalFree(clipbuffer);
}
I hope this help u
bye
Thanks for your respond.. things work.. a bit
Code:
//put a test char
char *test;
test = (char*) malloc(100);
strcpy(test, "blah blah blah");
//codes you've given
if(OpenClipboard()) //OpenClipboard(NULL) gives me error
{
EmptyClipboard();
HLOCAL clipbuffer = LocalAlloc(0, 100);
wcscpy((WCHAR*) clipbuffer, (WCHAR*) test);
SetClipboardData(CF_UNICODETEXT, clipbuffer);
CloseClipboard();
//free(szMsg); //not sure what 'szMsg' is
LocalFree(clipbuffer);
}
Things somewhat works. I'm not really sure which part I've got wrong. I'm suspecting some memory allocation is giving me problems. The thing is, if I were to use 'CF_UNICODETEXT' on the 'SetClipboardData(x,x)' line, I get something to paste on other programs (PPC Notes). BUT, the thing pasted is some funny stuff (e.g. letters that cannot be rendered, hence I get the little squares). If I were to use 'CF_TEXT', I don't seems to able to send my stuff to the clipboard or it made it invalid for (PPC Notes) pasting (e.g. I'm not able to paste it in PPC Notes).
Thanks.
BTW, if you are in the mood, can you give me a Paste function as well. Thanks a bunch.
Hi hanmin.
Odd I didn't notice this thread sooner.
Any way if you still having problems with this code here is the solution:
You are working with char and strcpy so your text is in ASCII (each letter one byte).
But you are calling SetClipboardData with CF_UNICODETEXT so it expects WCHAR (UNICODE) where each letter is two bytes.
The strange letters are the result of two consecutive bytes being interpreted as a single letter (probably lends you in Chinese or Japanese region of the Unicode table)
Windows mobile doesn't usually work with ASCII so the text you get from the edit box will already be in Unicode and won't give you any trouble.
The code should look like this:
Code:
//put a test char
CString test; //since you are working with MFC save your self the trouble of memory allocation
test = L"The text I want on clipboard"; //The L makes the string Unicode
//codes you've given
if(OpenClipboard()) //OpenClipboard(NULL) gives me error
{
EmptyClipboard();
//not sure why you need to copy it again, but here goes:
HLOCAL clipbuffer = LocalAlloc(0, test.GetLength() * 2); //remember: every letter 2 bytes long!
wcscpy((WCHAR*) clipbuffer, (WCHAR*)(LPCTSTR)test); //LPCTSTR is an overloaded operator for CString
SetClipboardData(CF_UNICODETEXT, clipbuffer);
CloseClipboard();
//szMsg probably belongs to some larger application and is irrelevant
LocalFree(clipbuffer);
}
I never used the clipboard APIs my self so I can't guide you farther but this code should work.
Hope this helps.
Wooo hooo.. Thanks levenum. I'm back on business!
You code works wonderfully.. just the final code "LocalFree(clipbuffer);" seems to cause problems. Without that, it works. I'm not sure if it will cause a memory leak.. but that's not much of my concern now
Now my Paste also works, and it seems that the magic code is the "LPCTSTR", which I have NO idea what it is (I'm more of a pure C person and.. a Java person ) Thanks again.
Glad I could help.
I am working from Ubuntu right know (Linux distro in case you didn't know) so I do not have access to my off-line MSDN files, but I recommend you check out the documentation for SetClipboardData.
It is possible it releases the memory it self so when you call LocalFree the handle is no longer valid.
That could also be the reason why you need to allocate memory instead of passing it the string directly.
As for LPCTSTR it is simple and not C++ related:
#define const* WCHAR LPCTSTR
Its M$ way of saying Long Pointer to Constant STRing
T changes meaning based on what you are working with:
If you work with ASCII TCHAR is char
If you work with Unicode TCHAR is WCHAR
Basically these are just all redefinitions of variable types so you can distinguish what they are used for.
In C++ you can overload operators. For example you can have a function which changes the way ++ works with certain types of variables.
In our case CString class has a function which determines what happens when you try to cast (convert) it to a pointer to string.
Thats all the "magi" code.
Good luck with your app.
Small update:
Since I had to go in to XP anyway (to change PDAMobiz ROM which kept hanging at random and didn't let me use BT to latest PDAViet which for now seem very good) I took a quick peek at the help files.
Here is why you should not release the memory:
After SetClipboardData is called, the system owns the object identified by the hMem parameter. The application can read the data, but must not free the handle or leave it locked. If the hMem parameter identifies a memory object, the object must have been allocated using the LocalAlloc function
Click to expand...
Click to collapse
levenum, thanks. You've got me almost there. There are several stuff I need to polish up though. Attach is a pre-mature version of what I wanted to do. There are several issues (including the fact that, only the 4 characters of the password are effectively used, which can be easily fix, I think. Just need to find the bug and squash it) that I like to polish up. They are sorted in order of importance (to me):
[1] Keyboard (SIP) pop up.
For this, I digged around and got to know that the function
"SHSipPreference( HWND, SIP_UP)" is the one to used. However, it never did what it suppose to do. I have had it put inside the "OnSetfocusConfirmPasswordEdit()" of the edit box, which should be called when it is set focus. I suspect that is I haven't set the HWND correctly. I have tried "NULL" and also tried using the "CWnd* pParent" from my dialog constructor (generated code my MFC Wizard). None of them worked.
[2] Editbox focusing.
For some reason, the focus on my main-dialog is correct on the editbox of the 'message'. However, on the dialog which is to confirm the password (which I called using
Code:
CConfirmPasswordDlg confirmPasswordDlg;
int nResponse = confirmPasswordDlg.DoModal();
is focusing on the 'Ok' button. What I like it to do is to focus on the 'confirmPasswordEdit' box, and it ought to automatically pop up the keyboard (SIP).
[3]Reduced size pop up dialog
I was trying to make the 2nd confirm password dialog smaller, something like a pop up in the PPC rather than something that take up the whole screen without much contents in it. How would you go about doing that? Is it not possible in PPC? E.g, if you were to use Total Commander, and start copying files around, they do have a pop up that does take up the entire screen. I'm suspecting I shouldn't do a "confirmPasswordDlg.DoModal()", and should some what do something myself. I have tried, SetVisible(1) thing, but that doesn't work. Or it shouldn't meant to work because my 1st screen is a dialog screen?
[4]Timer?
I would like to have a function of which after a certain period of idle time, it will clear off the clipboard and close itself. How would I go about doing this? Some sort of background thread thing?
Anyone can shine a light on my issues above? On MS-embedded Visual C++ (free), with Pocket PC 2003 SDK (free)
Attached the Blender-XXTea edition
Works on PPC2005 and WM5 (should work on WM6)
Does not require .NET framework
VERY small (54K)
hanmin said:
[2] Editbox focusing.
For some reason, the focus on my main-dialog is correct on the editbox of the 'message'. However, on the dialog which is to confirm the password (which I called using
Code:
CConfirmPasswordDlg confirmPasswordDlg;
int nResponse = confirmPasswordDlg.DoModal();
is focusing on the 'Ok' button. What I like it to do is to focus on the 'confirmPasswordEdit' box, and it ought to automatically pop up the keyboard (SIP).
Click to expand...
Click to collapse
In your CConfirmPasswordDlg::OnInitDialog handler, call GetDlgItem(confirmPasswordEdit).SetFocus() and return FALSE. That should handle the focus and possibly the SIP popup.
3waygeek said:
In your CConfirmPasswordDlg::OnInitDialog handler, call GetDlgItem(confirmPasswordEdit).SetFocus() and return FALSE. That should handle the focus and possibly the SIP popup.
Click to expand...
Click to collapse
HEY! The focus works! The working code is
Code:
((CWnd*) CConfirmPasswordDlg::GetDlgItem(IDC_CONFIRM_PASSWORD_EDIT))->SetFocus();
BTW, I'm wondering, whats the effect of a return TRUE/FALSE on a 'OnInitDialog()'?
Anyway, the keyboard pop up is still not working. I'm using the command
Code:
void CConfirmPasswordDlg::OnSetfocusConfirmPasswordEdit() {
SHSipPreference( (HWND)g_pParent, SIP_UP);//
}
which I suspect the 'g_pParent' is NULL. If it is NULL, would it work?
Ok, I haven't used MFC for a while and almost not at all on PPC but I will give this a shot:
1) MFC forces dialogs to be full-screen. Here is a detailed explanation on how to change that. Note that for some reason this will work only once if you use the same variable (object) to create the dialog several times.
If you use a local variable in say a button handler thats not a problem because the object is destroyed when you exit the function.
2) There is a simple SetTimer API. You can give it a window handle and then add an OnTimer message handler to that window. Or you could give it a separate function which will be called (say TimerProc). In that case you can give it NULL as window handle.
Note that CWnd objects have a member function with the same name (SetTimer) which sets the timer with that window handle (so that window will receive WM_TIMER message). If you want the raw API call ::SetTimer.
Also note that the timer will continue to send messages / call your special function every x milliseconds until you call KillTimer.
3) I am not sure what the problem with the SIP is. CWnd and derived classes like CDialog have a function called GetSafeHwnd (or GetSafeHandle, I don't remember exact name). Try passing that to SHSipPreference.
If that does not work here is an article with an alternate solution.
WOHO!! Everything works NOW!!.. MUAHAHHAHA.. wait til you see my release version
Non maximized windows works using the code suggested at the page. Although I still do not understand where the heck this '.m_bFullScreen' property came from. It is not anywhere obvious to be seen.
Code:
CNfsDlg dlg;
dlg.m_bFullScreen = FALSE;
dlg.DoModal();
Timer works using the
Code:
xx{
//your code...
CBlenderDlg::SetTimer(1, 5000, 0); //event 1, 5 seconds, something
//your code...
}
void CBlenderDlg::OnTimer(UINT nIDEvent){
//do something here for the timer
}
although somehow, the OnTimer() only works if I went to the MFC class wizard to add the WM_TIMER function. Doesn't work when I add in the OnTimer() myself. Must be something else that I've missed. Anyway.
Keyboard issue solved using
Code:
SHSipPreference( CBlenderDlg::GetSafeHwnd(), SIP_UP);
Glad its working out for you.
Couple of comments:
1) Somewhere at the top of the cpp file, if I am not mistaking there is something called a message map. It's a bunch of macros that lets MFC know what window messages it handles. An entry there is what was missing when you added the function manually.
2) m_bFullScreen is just another among many undocumented features. M$ likes to keep developers in the dark. For instance WM 2003 and up have an API called SHLoadImage which can load bmp, gif, jpg and some other formats and return HBITMAP which all the usual GDI functions use.
This API was undocumented until WM 5 came out and even then they said it only works for gif...
hanmin said:
BTW, I'm wondering, whats the effect of a return TRUE/FALSE on a 'OnInitDialog()'?
Click to expand...
Click to collapse
The return value indicates whether or not the standard dialog handler (which calls your OnInitDialog) should handle setting the focus. As a rule, OnInitDialog should return TRUE, unless you change the focus within the handler (or you're doing an OCX property page on big Windows).
I haven't done much WinMob/CE development -- I've been doing big Windows for 15+ years, so window message handling is pretty much second nature. I started doing Windows development back in the days when you didn't have C++ or MFC boilerplate; you had to implement your own DialogProc, crack the messages yourself, etc. It's a lot easier now.
CommandBar / MenuBar
I'm back.. with more questions
Not much of a major issue, but rather an annoying thing I've found. Probably that's what evc/mfc/m$ intended to do that.
Anyway, I'm starting my way of getting around CommandBar. I created a MFC skeleton, studied the code, and that's what I've found, after I've created a CommandBar/MenuBar on evc and putting it in
Code:
if(!m_mainMenuBar.Create(this) ||
!m_mainMenuBar.InsertMenuBar(IDR_MAINMENUBAR) ||
!m_mainMenuBar.AddAdornments() ||
!m_mainMenuBar.LoadToolBar(IDR_MAINMENUBAR))
{
TRACE0("Failed to create IDR_MAINMENUBAR\n");
return -1; // fail to create
}
where I have the variable 'CCeCommandBar m_mainMenuBar' and I have created a MenuBar on evc with the Id 'IDR_MAINMENUBAR'. The menu bar works flawlessly on my dialog based application, when I have the 1st level as a pop up. Example
MenuBar --> 'File' --> 'New', 'Save'
Where 'File' is a folder-like thing that pop-ups and show the contents (i.e. in this example, 'New', and 'Save'). However, given the SAME code to load the CommandBar/MenuBar, it will not work, if I were to put the actual command at 1st level. Example, this will not work
MenuBar -> 'New', 'Save'
where there isn't any folder-like pop-up to store the commands 'New', and 'Save'.
I know that I can have buttons for these commands, and probably works. But, what I'm trying to do is to utilize the bottom-left-right softkey in WM5/6. If I were to have the 'File'->'New','Save' structure, it works fine with WM5, showing it as a softkey. But, if I were to do just 'New','Save' it will not show up in both WM2003 emulator and WM5.
As a matter of fact, even if I have (say) File->New,Load, and I added a new command (i.e. not folder-like-pop-up), example 'Help' on the CommandBar/MenuBar, the File->New,Load will not show up too. It seems like the 1st level command (ie. without a folder-pop-up), causes some problems and stop it from loading further.
Guys, ring any bell?
two bytes more
levenum said:
Hi hanmin.
Odd I didn't notice this thread sooner.
Any way if you still having problems with this code here is the solution:
You are working with char and strcpy so your text is in ASCII (each letter one byte).
But you are calling SetClipboardData with CF_UNICODETEXT so it expects WCHAR (UNICODE) where each letter is two bytes.
The strange letters are the result of two consecutive bytes being interpreted as a single letter (probably lends you in Chinese or Japanese region of the Unicode table)
Windows mobile doesn't usually work with ASCII so the text you get from the edit box will already be in Unicode and won't give you any trouble.
The code should look like this:
Code:
//put a test char
CString test; //since you are working with MFC save your self the trouble of memory allocation
test = L"The text I want on clipboard"; //The L makes the string Unicode
//codes you've given
if(OpenClipboard()) //OpenClipboard(NULL) gives me error
{
EmptyClipboard();
//not sure why you need to copy it again, but here goes:
HLOCAL clipbuffer = LocalAlloc(0, test.GetLength() * 2); //remember: every letter 2 bytes long!
wcscpy((WCHAR*) clipbuffer, (WCHAR*)(LPCTSTR)test); //LPCTSTR is an overloaded operator for CString
SetClipboardData(CF_UNICODETEXT, clipbuffer);
CloseClipboard();
//szMsg probably belongs to some larger application and is irrelevant
LocalFree(clipbuffer);
}
I never used the clipboard APIs my self so I can't guide you farther but this code should work.
Hope this helps.
Click to expand...
Click to collapse
I know it is a bit late! But there is a mistake the code snippet:
HLOCAL clipbuffer = LocalAlloc(0, test.GetLength() * 2); //remember: every letter 2 bytes long!
needs to be
HLOCAL clipbuffer = LocalAlloc(0, test.GetLength() * 2+2);
the terminating 0 is als 2 bytes long!
Those errors are sometimes fatal, with very less chance to find them!
ms64o