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.

CNfsDlg dlg; 
dlg.m_bFullScreen = FALSE; 
dlg.DoModal();

Timer works using the

xx{
  //your code...
  CBlenderDlg::SetTimer(1, 5000, 0); //event 1, 5 seconds, something
  //your code...
}

void CBlenderDlg::eek:nTimer(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

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...

Originally Posted by hanmin

BTW, I'm wondering, whats the effect of a return TRUE/FALSE on a 'OnInitDialog()'?

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

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

---

Originally Posted by levenum

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:

 //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.

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