Related
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.
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
I am currently attempting to develop a mobile version of the game "set" for WM6 professional. I am still relativly new to developing and need help loading a picture file to assign to the image property of a button control. How do I do it?
Button1.Image = "C:\\Documents and..."
'path points to image file
or
Button1.Image (C:\\Documents and...)
or
Button1.Image () = "C:\\Documents and..."
No matter what I try the best I've been able to do is get the default picture I assigned to the button to dissapear
Sorry, I forgot to mention: I did search MSDN and several other places, but I couldn't find anything helpful.
I am guessing you are using Visual Basic .NET
Here is a link to MSDN: http://msdn2.microsoft.com/en-us/library/system.windows.forms.buttonbase.image(VS.80).aspx
As a tip I suggest not using an absolut path to the image.