New Windows Mobile Starter Kits

There are some new Windows Mobile Starter Kits published recently on MSDN demonstrating different technologies include DirectDraw on mobile applications, WIndows Mobile Ink APIs, Home Screen APIs, etc.


A starter kit is a useful and ready-to-run project which helps developers to understand the concepts of various technologies. It comes with a detailed documentation which helps developers to understand the code and structure of the programming project in the starter kit. Developers can develop their own application based on the existing starter kits.


The following link on MSDN explains the details of the starter kits and provides links for you to download them.


http://msdn2.microsoft.com/en-us/windowsmobile/bb264330.aspx

Windows Mobile Ink: The Correct Way of Getting Recognition Results

 


Windows Mobile Ink APIs are new in Windows Mobile 6 SDK. I guess they are trying to replace the old RichInk APIs.


The way of using Windows Mobile Ink is not complex. The basic idea is to have a IInkOverlay object as an ink collector; an IInkDisp object as a container of strokes data; an IInkStrokes object as a collection of IInkStrokeDisp object. The IInkOverlay object collects the ink data and put them in the IInkDisp object. Then the IInkDisp object put the strokes to the IInkStrokes object.


When the strokes data are in the IInkStrokes object, it’s time to get the best recognition result. Currently there are two ways of doing that. One is to directly use the ToString() method to get the best recognition result; the other is to create an IInkRecognitionResult object and use get_RecognitionResult property to get the recognition result set from the IInkStrokes object, then use get_TopString() property to get the best fit result and put it in the BSTR. 


 /**


* pInkStrokes is the IInkStrokes object. 


* pInkRecognitionResult is the IInkRecognitinoResult object.  


* StringRecognitionResult is the BSTR.


**/


//Get the best recognition result to the IInkRecognitionResult object


pInkStrokes->get_RecognitionResult(&pInkRecognitionResult);


//Get the best recognition result to the BSTR


pInkRecognitionResult->get_TopString(&StringRecognitionResult);


 


The first way, using ToString(), seems to be much easier than the second way which is to use IInkRecognitionResult object; However, ToString() is not recommended to be used in this case. I’ve ever mistakenly used ToString() in this case and had some strange exceptions raised (i.e. WinCE501bException) when my application is not used properly. As the result the correct way of getting ink recognition results is to use IInkRecognitionResult object and its properties.

Windows Mobile: Getting Screen Size Information Before Main Window Is Loaded

I wanted to develop a screen size aware application, which will draw all application dialogboxes and windows dynamically depends on the actual screen size of the device. It will not be that hard to adapt the main application window to the screen size because GetWindowRect() or GetClientRect() functions can be used to get the screen size when the main window is loaded.


However, if the application has a pop-op dialogbox for user to do some selections before the main window is loaded, how can I make the dialogbox aware of the screen size? Since main application window hasn’t loaded yet so GetWindowRect() and GetClientRect() won’t get the correct value for screen size.


I thought about it, asked people around me and looked for some related resources, then I found two solutions.


The first way of doing it is to use GetSystemMetrics() function. It can get the screen size even the main application window hasn’t been loaded yet. So if I define two int variables height and width, then I can set:


height = GetSystemMetrics(SM_CYSCREEN);


width = GetSystemMetrics(SM_CXSCREEN);


Then I can use MoveWindow() under WM_INITDIALOG message handler to make the dialogbox aware of screen size.


The second way of doing it can be delaying the display of the dialogbox until main window is initialized (not necessarily shown). To implement it this way, I need to have a global integer variable storing the state of the application. It can be set to a specific value, then as the main window has been initialized, set the global integer to another value. Then have a test of the value, to judge when to display the dialogbox. At the time the dialogbox can be displayed, main application window is already initialized so GetWindowRect() function can return the appropriate screen size information. 

Using Remote Spy++ To Check Window Messages in Windows Mobile Applications

Windows programming in native C++ is generally considered far more complex than in managed code. Programming for Windows Mobile devices is very similar with Windows programming. Sometimes we need to figure out which Window message is sent so we can write the corresponding event handling code. However, we can’t use Spy++ to do so because we are either debugging our application in the device emulator which is a virtual machine or an actual device.


Visual Studio has a tool called Remote Spy++ (with an array of other remote tools), which provides us the functionality to work with device emulators and/or  actual connected devices. So if you don’t know this guy yet and want to use Spy++ for your device application, you can go ahead and try. It’s pretty cool and may save you a lot of work to watch for the right messages.

Some Media Interviews

On Technet Blog IT Managers Connection:

http://blogs.technet.com/cdnitmanagers/archive/2007/04/17/interview-part-1-nuo-yan-windows-shell-user-mvp.aspx

http://blogs.technet.com/cdnitmanagers/archive/2007/04/18/interview-part-2-nuo-yan-windows-shell-user-mvp.aspx

http://blogs.technet.com/cdnitmanagers/archive/2007/04/19/interview-part-3-nuo-yan-windows-shell-user-mvp.aspx

Also can be found at:

http://www.stephenibaraki.com/cips/v47/nuo_yan.html

http://www.npanet.org/public/interviews/careers_interview_267.cfm

On Microsoft.com:

http://www.microsoft.com/presspass/events/mvpsummit/docs/MVPYanNCS.doc

 

Access-Based Enumeration is in Windows Vista

Windows Vista supports to share a single file to one or more users. This is truely a great news for all Windows users since we don’t have to share a whole folder only for a file. But more excited, Access-Based Enumeration is used for sharing single file.


What is Access-Based Enumeration?


Usually when we share something on our computer, we prevent illegal access by providing different users different permissions. When those users connect to the share folder, all of them are still able to see all of the contents listed, no matter they have permissions to read or write or not. If they don’t have right permissions for some contents, they are not able to do the expected operation but they are able to see the contents listed.


Access-Based Enumeration controls the listing of the share folder based on access permissions. Users accessing sharing resources will not see those contents which they don’t have correct permissions to access. Access-Based Enumeration is first included in Windows Server 2003 Service Pack 1 and provided a tool called abetool.exe.


Where can I find Access-Based Enumeration in Windows Vista?


No. You may not be able to find something like an interface or tool. However, when you use Windows Vista to share a single file, you can experience the concept and advantage of Access-Based Enumeration.


Windows Vista allows a user to share a single file with one or more specified users. If one user named A is sharing a file named FILE to B and sharing another file named FILE1 to C, and C doesn’t have permission to see FILE and B doesn’t have permission to see FILE1. In this case, when B connects to A’s sharing resources, she is only able to see FILE listed but not FILE1; when C connects to A’s sharing resources, he is only able to see FILE1 listed but not FILE. If A also shared both files with user D, then D can see two files listed in A’s sharing resources.


This feature increases the working efficiency for the information workers and increases the overall security in a sharing environment.

TechEd Session Date Confirmed

TechEd 2006 Boston


SVR219 – Ten Reasons to Prepare for Windows Server Code Named “Longhorn”


6/14/2006 10:15 – 11:30


SVR219R – Ten Reasons to Prepare for Windows Server Code Named “Longhorn”


6/14/2006 15:45 – 17:00 (Repeat Session)


Presenter: Ward Ralston– Group Product Manager – Windows Server Division


Co-Presenter: Nuo Yan – Microsoft MVP – Windows Shell / User


Welcome to come!


In addition, our session has been selected to the TechEd Webcasts program so we will have a chance to delivery the course online before TechEd! If you can’t make the trip to Boston, join us online. I will publish dates and detail information when they become available.


 

How to Use Terminal Services Manager

You may be interested  to take a look at my new How-To article at howtonetworking.com:


How to Use Terminal Services Manager (Beginner Level)


http://www.howtonetworking.com/RemoteAccess/tsmanager.htm


The article describes how to use the Terminal Services Manager MMC in Windows Server 2003 to perform basic and some advanced Terminal Services sessions management such as connecting / disconnecting to sessions, logging of and remote control users’ sessions and managing the processes in the users’ sessions, etc.