Wednesday, June 04, 2008
Thank you for attending the developer session with the title of this blog post. Below are some resources for you.
- Download the slides and demos for this talk here.
- For my relevant blog posts, follow all the links (the hyperlinked numbers 1-9) from this blog post.
- Best of all, ignore all of the above, and just read my MSDN mag article which I link to from here.
- Download the slides and demos for this talk here.
- For my relevant blog posts, follow all the links (the hyperlinked numbers 1-9) from this blog post.
- Best of all, ignore all of the above, and just read my MSDN mag article which I link to from here.
Labels: Mobile and Embedded
Saturday, May 17, 2008
Catching up with my inbox I found a message that our book is now translated to Chinese! Peter beat me to it with sharing the news so go over to his blog post with an image of the cover.
Labels: Mobile and Embedded
Thursday, December 20, 2007
When the Windows Mobile Managed APIs were introduced they made use of a new underlying Windows CE 5 feature (that WM 5.0 is based on): volatile registry keys (see dwOptions). Volatile keys are also available on normal/desktop/server Windows. In a nutshell, volatile registry keys do not survive an OS reboot so anything you write there is not persisted the next time you restart. The obvious question at this point is: Does the managed registry API support volatile keys? The answer is "no" for both the full .NET Framework and the .NET Compact Framework. Let's explore an UNSUPPORTED solution for both platforms.
On the surface without too much digging it appears that the native RegCreateKeyEx is wrapped by RegistryKey.CreateSubKey. So for the BCL team to add support for volatile keys to the managed API, one way would be to add a new overload to CreateSubKey that accepts our desire for volatileness and at the point it calls RegCreateKeyEx it passes in REG_OPTION_VOLATILE instead of 0 which is what the implementation does now (i.e. a change of one line of code).
But since we are not the BCL team and we cannot edit the library's code, we can create a helper static method to do that job for us. Maybe that method would live in the static Program class with a signature something like this:
1. I've made the method an extension method which means that we can call it in either of these two ways (the first being more natural):
a) Where the framework's implementation passes 0 as the 4th argument to the native RegCreateKeyEx, we will pass REG_OPTION_VOLATILE.
b) Wherever the framework's implementation calls private/internal methods we will have to use reflection to access them (unless you fancy duplicating all of that too;)).
Yes, I know the above is very ugly, very unsupported and very much a hack. I have created a VS2008 solution with the above that you can use to test it out at your own risk. It contains two projects, one for NETCF to run on your Windows Mobile and one for the desktop.
It is quite possible that by running the code from the project your machine will be wiped clean and that your monitor will go up in flames after transferring all your money out of your bank account. You have been warned!
So, at your own risk, get the VS2008 projects here.
On the surface without too much digging it appears that the native RegCreateKeyEx is wrapped by RegistryKey.CreateSubKey. So for the BCL team to add support for volatile keys to the managed API, one way would be to add a new overload to CreateSubKey that accepts our desire for volatileness and at the point it calls RegCreateKeyEx it passes in REG_OPTION_VOLATILE instead of 0 which is what the implementation does now (i.e. a change of one line of code).
But since we are not the BCL team and we cannot edit the library's code, we can create a helper static method to do that job for us. Maybe that method would live in the static Program class with a signature something like this:
public static RegistryKey CreateSubKey(this RegistryKey rk, string subkey, bool isVolatile)Note on the above:
{
if (!isVolatile)
{
return rk.CreateSubKey(subkey); // i.e. no change
}
else
{
// call our own method since we cannot change the framework's
return MothCreateVolatileSubKey(rk, subkey, RegistryKeyPermissionCheck.Default);
}
}
1. I've made the method an extension method which means that we can call it in either of these two ways (the first being more natural):
RegistryKey rk1 = Registry.CurrentUser.CreateSubKey("my vol", true);
RegistryKey rk2 = Program.CreateSubKey(Registry.CurrentUser, "my vol", true);2. As you can imagine the implementation of MothCreateVolatileSubKey is a simple duplication of the implementation of the existing framework method with 2 differences:a) Where the framework's implementation passes 0 as the 4th argument to the native RegCreateKeyEx, we will pass REG_OPTION_VOLATILE.
b) Wherever the framework's implementation calls private/internal methods we will have to use reflection to access them (unless you fancy duplicating all of that too;)).
Yes, I know the above is very ugly, very unsupported and very much a hack. I have created a VS2008 solution with the above that you can use to test it out at your own risk. It contains two projects, one for NETCF to run on your Windows Mobile and one for the desktop.
It is quite possible that by running the code from the project your machine will be wiped clean and that your monitor will go up in flames after transferring all your money out of your bank account. You have been warned!
So, at your own risk, get the VS2008 projects here.
Labels: dot NET general, Mobile and Embedded
# posted by The Moth @ 12:48:00 PM 
Tuesday, October 30, 2007
Three years ago I was speculating about this very topic, and was planning to implement it for the company I worked for at the time. I never got the chance, but the OpenNETCF guys delivered Padarn today! Very cool...
Labels: Mobile and Embedded
# posted by The Moth @ 3:11:00 AM
Wednesday, September 26, 2007
Loke Uei has a cool walkthrough of using PowerShell to talk to the Device Emulator via the new managed CoreCon APIs. Check it out.
Labels: Mobile and Embedded
# posted by The Moth @ 5:17:00 PM
Friday, September 21, 2007
Steven only posts once in a blue moon but when he does every .NET Compact Framework developer should take notice. Read the details of the GC Heap data file format.
Labels: Mobile and Embedded
# posted by The Moth @ 2:30:00 PM
Thursday, September 13, 2007
If you are playing with Beta 2 of NET CF 3.5 then you are probably missing the brand new diagnostic/performance/configuration/etc tools. Well now there are more than ever before and available in the form of a Power Toys package that you can get here.
[Source: NETCF blog]
[Source: NETCF blog]
Labels: Mobile and Embedded
# posted by The Moth @ 1:05:00 AM
Tuesday, July 24, 2007
It looks like the world has gone crazy with this Facebook thingy. I have zero time for real socialising let alone for online socializing so I have ignored the whole thing. By "ignored", I mean I have acted on invitations (meaning I had to create my space or whatever it is called) and other things that come into my email inbox, but I have not customised anything or initiated connections/invitations or even uploaded a photo. So why am I talking about it here?
It turns out that there is a .NET API for Facebook! It also looks like supreme device developer and all around top geezer, The Foot, has started porting it to support the .NET Compact Framework. Check out his blog post for more (which follows on from this one that includes screenshots).
It turns out that there is a .NET API for Facebook! It also looks like supreme device developer and all around top geezer, The Foot, has started porting it to support the .NET Compact Framework. Check out his blog post for more (which follows on from this one that includes screenshots).
Labels: Links, Mobile and Embedded
# posted by The Moth @ 3:20:00 PM
Wednesday, July 18, 2007
A little known brand new feature in Windows Mobile 6 is the ability to do inking using the same technology as for the Tablet PC (Windows Ink Service Platform). Luis talks about it on the WM blog with a code example. One of the commenters of that blog post asked for a managed version (I don't blame him; in this day and age what was the WM dev team thinking?!). To get a managed version (and a bit more info on the API) go to Alex's blog and look for the hidden links.
Labels: Mobile and Embedded
# posted by The Moth @ 4:33:00 AM
Monday, July 16, 2007
Via David I found this WM security blog post and via that I found this old but great WM security article.
After you consume the info above (and most of my trusted mobile dev readers will already know that stuff) then you are left craving for a pretty and concise diagram that illustrates the flow of an app's execution on Windows Mobile. I hope your craving is satisfied with the following (thanks Mark!):
At some future point you should expect to see the diagram linked somewhere from this excellent page of security resources for Device Projects.
After you consume the info above (and most of my trusted mobile dev readers will already know that stuff) then you are left craving for a pretty and concise diagram that illustrates the flow of an app's execution on Windows Mobile. I hope your craving is satisfied with the following (thanks Mark!):
At some future point you should expect to see the diagram linked somewhere from this excellent page of security resources for Device Projects.
Labels: Mobile and Embedded
# posted by The Moth @ 4:41:00 PM
Friday, July 13, 2007
Occasionally I get people asking me about developing web apps that are accessible from Windows Mobile. Every time I explain how with something as powerful as the .NET Compact Framework, they should be writing smart clients on the device that can also work in offline mode, cache data and offer a richer user experience. These apps can then access their server as needed either via web services or via some kind of SQL synchronization mechanism if that is what they are using on their backend. Some people insist though on offering a suboptimal solution to their customers so what answer do we have for those? Head over to Thom's blog to explore Mobile Web Development with ASP.NET.
A related question I hear is "what capabilities does Pocket Internet Explorer (PIE) offer?". Well, it is not called that anymore, it is IE Mobile and there is a homonymous blog. Visit their blog for tons of useful info, including the standards support in IE Mobile.
Finally, one of the co-authors of my book wrote in the distant past a book on mobile web dev that you may be interested in.
PS: Might as well link to my answer for the often asked question about Silverlight for Mobile.
A related question I hear is "what capabilities does Pocket Internet Explorer (PIE) offer?". Well, it is not called that anymore, it is IE Mobile and there is a homonymous blog. Visit their blog for tons of useful info, including the standards support in IE Mobile.
Finally, one of the co-authors of my book wrote in the distant past a book on mobile web dev that you may be interested in.
PS: Might as well link to my answer for the often asked question about Silverlight for Mobile.
Labels: Mobile and Embedded
# posted by The Moth @ 9:06:00 AM
Thursday, June 28, 2007
The MEDC world tour is over and my contribution was participating in panels and presenting at two locations: Las Vegas and Berlin. In both the US and the European events I delivered the sharing assets and the mobile UI tips sessions. You can find the powerpoint slides from both my breakouts in this ZIP file (tip: some of the slides have URLs for more info at the bottom).
Labels: Mobile and Embedded
# posted by The Moth @ 11:17:00 PM
Sunday, June 24, 2007
A few people asked me this week for my material for the Windows Mobile session I did at DevDays last week.
You can get the demos from this post. What you'll also find from there are links to screencasts I have done and other relevant blog posts. Note that even though those demos are for WM5 projects running in VS2005, the code is identical to what I showed in VS2008 Beta 1 targeting WM6 – no code change whatsoever.
Download the slides here (pptx inside another ZIP). If you are on a legacy version of powerpoint, see this post.
You can get the demos from this post. What you'll also find from there are links to screencasts I have done and other relevant blog posts. Note that even though those demos are for WM5 projects running in VS2005, the code is identical to what I showed in VS2008 Beta 1 targeting WM6 – no code change whatsoever.
Download the slides here (pptx inside another ZIP). If you are on a legacy version of powerpoint, see this post.
Labels: Mobile and Embedded
# posted by The Moth @ 3:16:00 AM
Tuesday, June 19, 2007
In this post I assume you have read my blog entry on Extension Methods. When I described extension methods I finished by saying:
So to quote myself from the article:
When we faced this issue in the SDF from OpenNETCF, we took one decision in some cases (utility classes) and the other decision (inheritance) in other cases. Unfortunately, utility classes suffer from the inherent non-discoverability for client code and inheritance is not always possible due to sealed classes. So many times we opted for a 3rd approach (that I was never entirely comfortable with): Introducing a replacement class e.g. TextBox2. Now, there are still scenarios where that approach is the only viable technique, but for some cases using the Extension methods as I describe in the article is a better alternative.
I'll just give one more example here. If we wanted the System.Windows.Forms.Timer class in the NETCF to have a compatible interface with the desktop version, one thing we'd have to do is add Start and Stop methods. Easily achieved by dropping the following code file in just the device project and not the desktop project:
"Overall, I like this feature *a lot* (will post some concrete examples of why in the future)."The time has come to explain myself. I've been waiting for my MSDN magasine article to go live so it can be the first to describe the proposed usage :-)
So to quote myself from the article:
"While using .NET Compact Framework classes, the occasion often arises that a particular class has members missing compared to the full Framework. Typically, developers have to write the missing functionality themselves and then decide whether to use inheritance if possible to add the missing members or add them to a utility helper class."Please visit the article to see a good example of how extension methods can help with the above scenario.
When we faced this issue in the SDF from OpenNETCF, we took one decision in some cases (utility classes) and the other decision (inheritance) in other cases. Unfortunately, utility classes suffer from the inherent non-discoverability for client code and inheritance is not always possible due to sealed classes. So many times we opted for a 3rd approach (that I was never entirely comfortable with): Introducing a replacement class e.g. TextBox2. Now, there are still scenarios where that approach is the only viable technique, but for some cases using the Extension methods as I describe in the article is a better alternative.
I'll just give one more example here. If we wanted the System.Windows.Forms.Timer class in the NETCF to have a compatible interface with the desktop version, one thing we'd have to do is add Start and Stop methods. Easily achieved by dropping the following code file in just the device project and not the desktop project:
public static class TimerExtensions...and then the codefile that uses the Timer can be the same on both platforms, e.g.
{
public static void Start(this Timer t)
{
t.Enabled = true;
}
public static void Stop(this Timer t)
{
t.Enabled = false;
}
}
private void menuItem1_Click(object sender, EventArgs e)We have seemingly added extra methods to a class so our utility methods are discoverable and if the real NETCF class ever got those methods implemented, our code gracefully bows out at runtime. Try it out... coding is believing how cool this is :)
{
timer1.Start();
}
private void menuItem2_Click(object sender, EventArgs e)
{
timer1.Stop();
}
Labels: Mobile and Embedded
# posted by The Moth @ 10:11:00 AM
Monday, June 18, 2007
In my July MSDN magazine article, I have collected in a single place my tips for writing cross-platform managed code, in this case meaning code that targets both the Windows desktop and Windows Mobile. Even though the article was written with the .NET Compact Framework and the full .NET Framework in mind, most of the techniques apply in other scenarios as well.
Consider how many frameworks/CLRs we have today: .NET Compact Framework, full .NET Framework (aka desktop framework), .NET Micro Framework, Silverlight CLR, MONO (framework for non-Windows platform) etc. To that list you should add scenarios where you wish to target two different versions of the same framework type e.g. both v1.0 and v2.0 of the NETCF/Full Fx. Even though it looks the same, the framework/CLR between versions is effectively a different framework so again some of the principles in the article apply. Read the article here.
Consider how many frameworks/CLRs we have today: .NET Compact Framework, full .NET Framework (aka desktop framework), .NET Micro Framework, Silverlight CLR, MONO (framework for non-Windows platform) etc. To that list you should add scenarios where you wish to target two different versions of the same framework type e.g. both v1.0 and v2.0 of the NETCF/Full Fx. Even though it looks the same, the framework/CLR between versions is effectively a different framework so again some of the principles in the article apply. Read the article here.
Labels: Mobile and Embedded
# posted by The Moth @ 3:31:00 AM
Monday, June 11, 2007
Mobile Development Handbook
My book is now in my hands, and here is the proof... and another wobbly photo of the back :-D
At some point in 2006 I started writing a book and at some point in April 2007 we completed the project. I say "we", because I had two excellent co-authors, both long standing Device Application MVPs: Peter Foot and Andy Wigley. I would have liked to be able to say that I also am a .NET Compact Framework MVP, but unfortunately I lost that title when joining Microsoft last year as per the rules.
We explicitly targeted two audiences with our book and implicitly excluded one audience segment:
1. Existing C# and VB device developers - YES
If you are already targeting Windows Mobile devices you will know that all existing books talk about version 1.0 of the .NET Compact Framework and Visual Studio.NET 2003. Since those times there have been three service packs for v1.0, version 2.0 with two service packs and, of course, Visual Studio 2005. Furthermore, v3.5 is in Beta 1 right now as is Visual Studio "Orcas". Our book covers what is new in the .NET Compact Framework and Visual Studio 2005 compared to their predecessors. It also covers throughout the chapters, but also in a dedicated chapter, version 3.5 of the NETCF and VS "Orcas" for Devices.
2. Existing .NET developers who are complete newbies to device development - YES
There are millions of proficient .NET desktop developers that would like to know how to write code for their mobile device or generally want to find out how to transfer their skills or business logic to the mobile platform. The book's tone is certainly aimed directly to those developers by continually contrasting and comparing with desktop development as applicable, highlighting what is different or missing when doing device development.
3. Existing native device developers - NO
This book is all about managed code, but we never introduce any basic .NET concepts from scratch. We expect readers to know about those either through experience with previous versions of NETCF or through .NET desktop development. So if you are a native device developer, you should pick up another book to learn the basics of .NET. We also have made no assumptions of knowledge about the Windows CE and Windows Mobile platform. The reason is so desktop developers can get an introduction to the whole stack/environment and not just the dev platform and tools. So, as a native device developer, you will encounter concepts explained that you probably already are intimately familiar with.
Whether you are looking for a book to read cover-to-cover or for a reference that you go back to, this book will fulfil your needs. It isn't just a book on the raw technology, but more importantly it captures lessons from developers that have practised mobile and embedded development in the real world.
Mobile Development Handbook
My book is now in my hands, and here is the proof... and another wobbly photo of the back :-D
At some point in 2006 I started writing a book and at some point in April 2007 we completed the project. I say "we", because I had two excellent co-authors, both long standing Device Application MVPs: Peter Foot and Andy Wigley. I would have liked to be able to say that I also am a .NET Compact Framework MVP, but unfortunately I lost that title when joining Microsoft last year as per the rules.
We explicitly targeted two audiences with our book and implicitly excluded one audience segment:
1. Existing C# and VB device developers - YES
If you are already targeting Windows Mobile devices you will know that all existing books talk about version 1.0 of the .NET Compact Framework and Visual Studio.NET 2003. Since those times there have been three service packs for v1.0, version 2.0 with two service packs and, of course, Visual Studio 2005. Furthermore, v3.5 is in Beta 1 right now as is Visual Studio "Orcas". Our book covers what is new in the .NET Compact Framework and Visual Studio 2005 compared to their predecessors. It also covers throughout the chapters, but also in a dedicated chapter, version 3.5 of the NETCF and VS "Orcas" for Devices.
2. Existing .NET developers who are complete newbies to device development - YES
There are millions of proficient .NET desktop developers that would like to know how to write code for their mobile device or generally want to find out how to transfer their skills or business logic to the mobile platform. The book's tone is certainly aimed directly to those developers by continually contrasting and comparing with desktop development as applicable, highlighting what is different or missing when doing device development.
3. Existing native device developers - NO
This book is all about managed code, but we never introduce any basic .NET concepts from scratch. We expect readers to know about those either through experience with previous versions of NETCF or through .NET desktop development. So if you are a native device developer, you should pick up another book to learn the basics of .NET. We also have made no assumptions of knowledge about the Windows CE and Windows Mobile platform. The reason is so desktop developers can get an introduction to the whole stack/environment and not just the dev platform and tools. So, as a native device developer, you will encounter concepts explained that you probably already are intimately familiar with.
Whether you are looking for a book to read cover-to-cover or for a reference that you go back to, this book will fulfil your needs. It isn't just a book on the raw technology, but more importantly it captures lessons from developers that have practised mobile and embedded development in the real world.
Mobile Development Handbook
Labels: Links, Mobile and Embedded, Personal
# posted by The Moth @ 6:13:00 AM
Thursday, May 31, 2007
Finally, the world gets an up to date book on Mobile Development! You can browse it at amazon or look for it at your favourite book shop online or offline.
Its 600+ pages are spread over the following 18 chapters:
Its 600+ pages are spread over the following 18 chapters:
1. .NET Compact Framework—a Platform on the MoveI highly recommended you check it out, for example, on the publisher's official book page.
2. Building a Microsoft Windows Forms GUI
3. Using SQL Server 2005 Compact Edition and Other Data Stores
4. Catching Errors, Testing, and Debugging
5. Understanding and Optimizing .NET Compact Framework Performance
6. Completing the Application: Packaging and Deployment
7. Exchanging Data with Backend Servers
8. Networking
9. Getting Connected
10. Security Programming for Mobile Applications
11. Threading
12. Graphics Programming
13. Direct3D Mobile
14. Interoperating with the Platform
15. Building Custom Controls
16. Internationalization
17. Developing with Windows Mobile
18. Introducing .NET Compact Framework Version 3.5 and Visual Studio "Orcas"
Labels: Mobile and Embedded, Personal
# posted by The Moth @ 2:08:00 PM
Sunday, May 27, 2007
With Orcas Beta 1 you also get NETCF Beta 1 with a build number of 7066. The last public NETCF drop was in the January CTP (and remained unchanged in the March CTP) with a build number of 6282. I documented what was new in that build of v3.5 compared to v2.0 and added a couple more later. Those new APIs are all still in build 7066 and in addition we also get the ones below:
* System.Delegate gets a new CreateDelegate static method and the two associated properties: Method and Target.
* There are new types in the System.Security.Cryptography (in mscorlib): AsymmetricKeyExchangeDeformatter (and the Formatter) and RSAPKCS1KeyExchangeFormatter (and the Deformatter).
* X509 in System.dll: X509Store, X509CertificateCollection, ClientCertificates property on System.Net.HttpWebRequest and 4 enums in System.Security.Cryptography.X509Certificates (OpenFlags, StoreLocation, StoreName, X509FindType).
* DataGridCell was moved from system.windows.forms.datagrid.dll to system.windows.forms.dll
In addition to the list above (inc. the ones from my links above), I previously mentioned the headline NET CF features. Well, finally in this Beta 1 drop you can play with those! The LINQ implementation in System.Core.dll is now compatible with the desktop naming and we also get the LINQ to XML implementation in System.Xml.Linq. The Compact WCF implementation resides in the new assemblies System.ServiceModel.dll (dependencies of which include the new System.Runtime.Serialization.dll) and Microsoft.ServiceModel.Channels.Mail.dll. For a "Hello World" example, check out Mark's two blog posts.
If at this point you are ready to play with this stuff, then first visit this download page for two reasons:
1. It includes some additional new features that are not visible at the public API level that I describe in my posts.
2. If you proceed with the download you will actually be able to compile projects referencing the Compact WCF assemblies. Simply remove your existing "Microsoft .Net Compact Framework 3.5 Pre-Release" and install the download (same build number as above, but with correctly signed assemblies).
* System.Delegate gets a new CreateDelegate static method and the two associated properties: Method and Target.
* There are new types in the System.Security.Cryptography (in mscorlib): AsymmetricKeyExchangeDeformatter (and the Formatter) and RSAPKCS1KeyExchangeFormatter (and the Deformatter).
* X509 in System.dll: X509Store, X509CertificateCollection, ClientCertificates property on System.Net.HttpWebRequest and 4 enums in System.Security.Cryptography.X509Certificates (OpenFlags, StoreLocation, StoreName, X509FindType).
* DataGridCell was moved from system.windows.forms.datagrid.dll to system.windows.forms.dll
In addition to the list above (inc. the ones from my links above), I previously mentioned the headline NET CF features. Well, finally in this Beta 1 drop you can play with those! The LINQ implementation in System.Core.dll is now compatible with the desktop naming and we also get the LINQ to XML implementation in System.Xml.Linq. The Compact WCF implementation resides in the new assemblies System.ServiceModel.dll (dependencies of which include the new System.Runtime.Serialization.dll) and Microsoft.ServiceModel.Channels.Mail.dll. For a "Hello World" example, check out Mark's two blog posts.
If at this point you are ready to play with this stuff, then first visit this download page for two reasons:
1. It includes some additional new features that are not visible at the public API level that I describe in my posts.
2. If you proceed with the download you will actually be able to compile projects referencing the Compact WCF assemblies. Simply remove your existing "Microsoft .Net Compact Framework 3.5 Pre-Release" and install the download (same build number as above, but with correctly signed assemblies).
Labels: Mobile and Embedded
# posted by The Moth @ 8:43:00 AM
Thursday, April 19, 2007
While chatting with users of a new .NET language that will RTM later this year (Vulcan.NET), I asked what they were doing for .NET Compact Framework support. They had most of it pretty much sussed. They understood that the tool support is the biggest hurdle since, at the end of the day, their language compiles down to IL so there should be no issues.
That last statement is true except the NETCF CLR only understands a (very rich) subset of the entire IL set. It doesn't support some niche opcodes mostly used by managed C++ (which the NETCF does not support). I promised I'd find the list of what is supported and what isn't. Dan from the NETCF team has posted such a table on his blog and even though it was written for v2.0 it still holds true for v3.5 of the NETCF. Check it out here.
That last statement is true except the NETCF CLR only understands a (very rich) subset of the entire IL set. It doesn't support some niche opcodes mostly used by managed C++ (which the NETCF does not support). I promised I'd find the list of what is supported and what isn't. Dan from the NETCF team has posted such a table on his blog and even though it was written for v2.0 it still holds true for v3.5 of the NETCF. Check it out here.
Labels: Mobile and Embedded
# posted by The Moth @ 1:15:00 PM
Wednesday, March 28, 2007
While we looked at new features in NETCF 3.5 for the device developer, there are also tons of improvements in the IDE (VSD "Orcas"), the top 5 IMO being:
1. Unit Testing for Devices
Note that this also works for v2.0 device projects in Orcas too, yay!
2. New Project dialog
3. Device Emulator v3
This has all the goodness of Device Emulator v2.0 plus it can be automated/scripted via COM - the clue is the DEMComInterface.idl file in your DE installation directory.
4. Device Configuration Manager & Device Certificate Manager
Previously available as a powertoy for WM5. To see them in action, from your VS Orcas Tools menu, select Device Security Manager:
5. Windows Mobile 5 SDKs and .NET Compact Framework v2.0 SP2 in the box. No more need for separate downloads :)
1. Unit Testing for Devices
Note that this also works for v2.0 device projects in Orcas too, yay!
2. New Project dialog
3. Device Emulator v3
This has all the goodness of Device Emulator v2.0 plus it can be automated/scripted via COM - the clue is the DEMComInterface.idl file in your DE installation directory.
4. Device Configuration Manager & Device Certificate Manager
Previously available as a powertoy for WM5. To see them in action, from your VS Orcas Tools menu, select Device Security Manager:
5. Windows Mobile 5 SDKs and .NET Compact Framework v2.0 SP2 in the box. No more need for separate downloads :)
Labels: Mobile and Embedded
# posted by The Moth @ 10:35:00 AM
UPDATE: After Beta 1 I updated the text below with a new addition/screenshot and struck out the inapplicable text (bug fixed).
Nick blogged about this first, and Neil followed. Both have screenshots on their blogs so check them out.
If you ask me, we needed this simplicity for newbies to device development because the old approach was way too confusing. Having said that, previously I could create any project type in two clicks and now I need a lot more; so penalising the expert user is definitely the case here IMO. Rule number one of UI development: less clicks is good. Rule number two: offer two navigation paths: one for the novice, one for the expert.
Regardless of the above, before Orcas RTMs, we have to fix the combobox behaviour: When I select NETCF version 2.0 in the bottom combobox and then select a platform in the top, why the heck does the value in the bottom combobox revert to the default of 3.5? Rule number three of UI development: If I have made selection, don't revert it based on another selection on the same dialog! What makes it worst in this instance is that when selecting something in the top combobox, the bottom combobox is hidden out of view so the change goes unnoticed unless you are looking for it.
Also, again regardless to the above, I would expect those combobox values to be remembered between different launches but unfortunately they are not (yet?).
As of Beta 1, the dialog has a new addition at the bottom: a hyperlink to get new SDKs (e.g the WM6 SDKs).
Nick blogged about this first, and Neil followed. Both have screenshots on their blogs so check them out.
If you ask me, we needed this simplicity for newbies to device development because the old approach was way too confusing. Having said that, previously I could create any project type in two clicks and now I need a lot more; so penalising the expert user is definitely the case here IMO. Rule number one of UI development: less clicks is good. Rule number two: offer two navigation paths: one for the novice, one for the expert.
Also, again regardless to the above, I would expect those combobox values to be remembered between different launches but unfortunately they are not (yet?).
As of Beta 1, the dialog has a new addition at the bottom: a hyperlink to get new SDKs (e.g the WM6 SDKs).
Labels: Mobile and Embedded
# posted by The Moth @ 10:16:00 AM
Sunday, March 18, 2007
Whinge and you shall receive. 18 months ago I moaned about the lack of FileAs in Windows Mobile 5.0 and showed how to achieve that programmatically . WM6 offers it out of the box in the UI as you can see below :)
Labels: Mobile and Embedded
# posted by The Moth @ 5:41:00 AM
Friday, March 09, 2007
I am late with this news (stuck in a place with no network connection).
Build 7045 (ie 2.0.7045.0) of the .NET Compact Framework is out of the door. No need to copy/paste here what is fixed since it is described on the download page.
One of the big ones is new diagnostics (that finally work on Vista) and, as usual, Steven has all the details.
Build 7045 (ie 2.0.7045.0) of the .NET Compact Framework is out of the door. No need to copy/paste here what is fixed since it is described on the download page.
One of the big ones is new diagnostics (that finally work on Vista) and, as usual, Steven has all the details.
Labels: Mobile and Embedded
# posted by The Moth @ 8:40:00 AM
Thursday, February 15, 2007
Over the last two posts I enumerated additions to the .NET Compact Framework 3.5, and there will be more posts as more Orcas CTPs come out. In particular, the two headline items of NETCF 3.5 are not listed at all in my previous two blog entries and they are: Compact WCF and Compact LINQ.
1. I have mentioned before Compact WCF. It is not in the January CTP, but when it does appear I’ll let you know.
2. LINQ is a topic that I’ll be talking a lot more about with regards to the full framework 2.5. Once I've written a few posts on that, I will come back to indicate what is missing from Compact LINQ [1].
The best people to describe the headline features and focus areas of the NETCF 3.5 are the Compact Framework team of course and they have done so here.
Cheers
Daniel
[1] If you are familiar with LINQ already, note that in the Jan “Orcas” CTP the NETCF LINQ bits use the old namespaces (e.g. System.Query ) in line with the May 2006 LINQ CTP rather than move on to the new System.Linq namespace. They are obviously aligned in future versions. Namespaces aside, the Compact LINQ implementation largely lives in System.Core assembly like its big brother.
1. I have mentioned before Compact WCF. It is not in the January CTP, but when it does appear I’ll let you know.
2. LINQ is a topic that I’ll be talking a lot more about with regards to the full framework 2.5. Once I've written a few posts on that, I will come back to indicate what is missing from Compact LINQ [1].
The best people to describe the headline features and focus areas of the NETCF 3.5 are the Compact Framework team of course and they have done so here.
Cheers
Daniel
[1] If you are familiar with LINQ already, note that in the Jan “Orcas” CTP the NETCF LINQ bits use the old namespaces (e.g. System.Query ) in line with the May 2006 LINQ CTP rather than move on to the new System.Linq namespace. They are obviously aligned in future versions. Namespaces aside, the Compact LINQ implementation largely lives in System.Core assembly like its big brother.
Labels: Mobile and Embedded
# posted by The Moth @ 3:06:00 PM
Wednesday, February 14, 2007
All the API additions I listed in my previous .NET Compact Framework 3.5 post, are namespaces/types/members that were already present in the full dotnet Framework v2.0 and are now also part of the NETCF 3.5
Here I will list a couple of additions that are brand new:
* When querying the Platform property of the static OSVersion property of the System.Environment class, we get back the PlatformID enumeration. NETCF 2.0 had a smaller list than the full framework and now with 3.5 not only it catches up by adding the Unix value but it even goes further by adding a brand new value: Xbox (not a surprise if you read this).
If you ask me, the full framework team should also add this enumeration value for code compatibility.
The other addition is entirely specific to device development and hence lives under the Microsoft.WindowsCE.Forms assembly. The SystemSettings class gets a new property (to make a grand total of 2!) named WinCEPlatform that returns the homonymous enumeration which has 3 values: WinCEGeneric, PocketPC and Smartphone
(I guess we’ll have to learn to map those last two to WM6 professional and standard :-p)
Next I'll list the real headlines of NETCF v3.5
Here I will list a couple of additions that are brand new:
* When querying the Platform property of the static OSVersion property of the System.Environment class, we get back the PlatformID enumeration. NETCF 2.0 had a smaller list than the full framework and now with 3.5 not only it catches up by adding the Unix value but it even goes further by adding a brand new value: Xbox (not a surprise if you read this).
If you ask me, the full framework team should also add this enumeration value for code compatibility.
The other addition is entirely specific to device development and hence lives under the Microsoft.WindowsCE.Forms assembly. The SystemSettings class gets a new property (to make a grand total of 2!) named WinCEPlatform that returns the homonymous enumeration which has 3 values: WinCEGeneric, PocketPC and Smartphone
(I guess we’ll have to learn to map those last two to WM6 professional and standard :-p)
Next I'll list the real headlines of NETCF v3.5
Labels: Mobile and Embedded
# posted by The Moth @ 4:56:00 AM
Tuesday, February 13, 2007
Hot from the factory, get it here.
Just like the WM6 SDK, works fine on Vista on top of VS2005 SP1 as the screenshots show.
Just like the WM6 SDK, works fine on Vista on top of VS2005 SP1 as the screenshots show.
Labels: Mobile and Embedded
# posted by The Moth @ 6:19:00 AM
Monday, February 12, 2007
The next version number of the .NET Compact Framework is 3.5, compared to version number 2.0 that ships today. This is so the version numbers can align with v3.5 of the full framework (NetFx3.5). You can play with NETCF 3.5 in the Orcas Jan CTP.
Below is some new NETCF stuff that I found (v3.5.6282.0):
* Remember the EventWaitHandle class that I wrote 2 years ago? It is now part of the compact framework (System.Threading). As part of the addition, the inheritance hierarchies have changed so AutoResetEvent and ManualResetEvent now inherit from EventWaitHandle and not WaitHandle (making this blog entry half-obsolete :)).
* Remember the Stopwatch class that I wrote? It is now in the CF (System.Diagnostics).
* The Array class get the Resize method and some new Sort overloads.
* The CompilerGeneratedAttribute class from the System.Runtime.CompilerServices namespace is now added.
* The SerializationException class from the System.Runtime.Serialization namespace is added.
* System.Text.StringBuilder gets a new overload for the AppendFormat method and also both overloads of the AppendLine method.
* The System.Threading.Thread class gets the static MemoryBarrier method.
* The String class now contains the Contains method.
* A whole bunch of classes get a public Dispose method including GraphicsStream, FileStream, MemoryStream, StreamReader, StreamWriter, StringReader, StringWriter, TextReader, TextWriter and others.
* To support the next addition, the InvalidDataException class is added to the System.IO namespace in System.dll
* We get the entire System.IO.Compression namespace (i.e. GZipStream, DeflateStream, CompressionMode) from the System.dll
* Relevant to the previous addition, there is a new enum System.Net.DecompressionMethods that is the type of the new property AutomaticDecompression on the HttpWebRequest class.
* We get the entire System.Media namespace (SoundPlayer, SystemSound, SystemSounds) from the System.dll
* Mainly to support the previous addition, we get two classes in the System.ComponentModel namespace: AsyncCompletedEventArgs and AsyncCompletedEventHandler.
* The Trace class from the System.Diagnostics namespace only had 3 overloads of the Assert method. Now it becomes much more useful with 4 overloads for each of the methods Write, WriteIf, WriteLine and WriteLineIf. It also gets the Fail, Flush and Close methods. Add to that the new TextWriterTraceListener and tracing looks much better overall in NETCF v3.5
Stay tuned for more coming this week...
Below is some new NETCF stuff that I found (v3.5.6282.0):
* Remember the EventWaitHandle class that I wrote 2 years ago? It is now part of the compact framework (System.Threading). As part of the addition, the inheritance hierarchies have changed so AutoResetEvent and ManualResetEvent now inherit from EventWaitHandle and not WaitHandle (making this blog entry half-obsolete :)).
* Remember the Stopwatch class that I wrote? It is now in the CF (System.Diagnostics).
* The Array class get the Resize method and some new Sort overloads.
* The CompilerGeneratedAttribute class from the System.Runtime.CompilerServices namespace is now added.
* The SerializationException class from the System.Runtime.Serialization namespace is added.
* System.Text.StringBuilder gets a new overload for the AppendFormat method and also both overloads of the AppendLine method.
* The System.Threading.Thread class gets the static MemoryBarrier method.
* The String class now contains the Contains method.
* A whole bunch of classes get a public Dispose method including GraphicsStream, FileStream, MemoryStream, StreamReader, StreamWriter, StringReader, StringWriter, TextReader, TextWriter and others.
* To support the next addition, the InvalidDataException class is added to the System.IO namespace in System.dll
* We get the entire System.IO.Compression namespace (i.e. GZipStream, DeflateStream, CompressionMode) from the System.dll
* Relevant to the previous addition, there is a new enum System.Net.DecompressionMethods that is the type of the new property AutomaticDecompression on the HttpWebRequest class.
* We get the entire System.Media namespace (SoundPlayer, SystemSound, SystemSounds) from the System.dll
* Mainly to support the previous addition, we get two classes in the System.ComponentModel namespace: AsyncCompletedEventArgs and AsyncCompletedEventHandler.
* The Trace class from the System.Diagnostics namespace only had 3 overloads of the Assert method. Now it becomes much more useful with 4 overloads for each of the methods Write, WriteIf, WriteLine and WriteLineIf. It also gets the Fail, Flush and Close methods. Add to that the new TextWriterTraceListener and tracing looks much better overall in NETCF v3.5
Stay tuned for more coming this week...
Labels: Mobile and Embedded
# posted by The Moth @ 1:23:00 PM
Friday, February 09, 2007
Remember, you heard/saw it here first!
It looks like the Windows Mobile 6 SDKs are out. Gone are the “for Pocket PC” and “for Smartphone” monikers. Instead, there is Professional and Standard... another mark of the convergence of the two form factors no doubt :-)
As you can see from the images in this post, the install works great on VS2005 SP1 on Vista!
UPDATE: When they are back online I’ll let you know. Please take your complaints here.
UPDATE 2: They are back online and I've updated the link above. Additional information here.
It looks like the Windows Mobile 6 SDKs are out. Gone are the “for Pocket PC” and “for Smartphone” monikers. Instead, there is Professional and Standard... another mark of the convergence of the two form factors no doubt :-)
As you can see from the images in this post, the install works great on VS2005 SP1 on Vista!
UPDATE: When they are back online I’ll let you know. Please take your complaints here.
UPDATE 2: They are back online and I've updated the link above. Additional information here.
Labels: Mobile and Embedded
# posted by The Moth @ 7:31:00 PM
Thursday, February 08, 2007
I *think* engadget are the first to break the news that what was codename "Crossbow" is now officially Windows Mobile 6
Mel has the screenshots and links to reviews, Loke lists the developer features, Scott talks about the security improvements, John asks us to stay tuned for more and the Outlook Mobile team lists their favourite features .
Like Peter says, it will be hard to get devices in the early stages (typically takes 4-6 months), so the vast improvements in the emulator are most welcome.
Mel has the screenshots and links to reviews, Loke lists the developer features, Scott talks about the security improvements, John asks us to stay tuned for more and the Outlook Mobile team lists their favourite features .
Like Peter says, it will be hard to get devices in the early stages (typically takes 4-6 months), so the vast improvements in the emulator are most welcome.
Labels: Mobile and Embedded
# posted by The Moth @ 2:30:00 AM
Sunday, February 04, 2007
A few people have asked me for the code I used in my WM5 Managed API screencasts (part one, two, and three). While I can’t find that exact code, it was almost identical to what I used in my Tech Ed session last year, which luckily I could find. You may download the VS2005 project here.
Labels: Mobile and Embedded
# posted by The Moth @ 4:04:00 PM
Tuesday, January 16, 2007
A very long time ago I blogged a bit about the Windows Mobile 5.0 managed APIs (also see this).
Recently I also described how to work around installing the free WM5.0 SDK on Windows Vista.
With v5.0 now being the de facto standard of Windows Mobile devices out there and given that the next version of Windows Mobile fully supports these APIs, it is never too late to jump in and learn how to use them and what they are about. In December I wrote a short article for the msdn flash on this very topic (subscribe to the flash now if you don’t already!).
So, if you want to learn more about the WM v5.0/vNext managed APIs or need more proof that mobile development works fine on Vista, download my 3-part nugget, which I hinted at in the article:
Note: The first 2-3 minutes of all videos is the same introduction. The last 1-2 minutes of all videos is the same summary and links. The 17-19 minutes in between is the demo bit, different in each part of course.
Recently I also described how to work around installing the free WM5.0 SDK on Windows Vista.
With v5.0 now being the de facto standard of Windows Mobile devices out there and given that the next version of Windows Mobile fully supports these APIs, it is never too late to jump in and learn how to use them and what they are about. In December I wrote a short article for the msdn flash on this very topic (subscribe to the flash now if you don’t already!).
So, if you want to learn more about the WM v5.0/vNext managed APIs or need more proof that mobile development works fine on Vista, download my 3-part nugget, which I hinted at in the article:
Part 1: Configuration, Telephony and Forms [streaming file and zip download]
Part 2: Status [streaming file and zip download]
Part 3: PocketOutlook [streaming file and zip download]
Note: The first 2-3 minutes of all videos is the same introduction. The last 1-2 minutes of all videos is the same summary and links. The 17-19 minutes in between is the demo bit, different in each part of course.
Labels: Mobile and Embedded
# posted by The Moth @ 9:47:00 AM
Friday, January 05, 2007
Want to win 12 hours of free online training for Windows Mobile development from e-learning? Check out Mark’s blog for details.
Labels: Mobile and Embedded
# posted by The Moth @ 9:55:00 AM
Monday, January 01, 2007
Exactly two years ago on New Year's day, I wrote the Best of "The Moth" 2004 blog enrty where I picked my favorite blog entries out of 96 posts. Exactly one year ago I had to choose from 151 posts to find the ones I thought were the best in terms of content and the result was the Best of "The Moth" 2005.
The year of 2006 I made 142 blog entries and below are a select few. Happy New Year!
01. I didn't have a chance to play with it as much as I wanted to, but with very little public info available, this blog served it well: .NET Micro Framework, its product sheet and other NETMF links.
02. Recognising an idiom of the using statement.
03. A cute desktop feature implemented for the Windows Mobile/WinCE platform in a reusable NETCF control: TextBox cue banner.
04. A picture is worth a 100 words and a video is... a whole bunch of pictures! Check mine out following the instructions here for my nuggets.
05. A comprehensive collection of links for Windows Workflow Foundation (WF).
06. I collected the links to my 9 blog posts on sharing assets between desktop and mobile platforms in one place. Follow the numbered links.
07. The most controversial feature of Windows Vista is something every developer must understand: User Account Control.
08. One of Vista's features is becoming my obsession and that is SideShow. My series of SideShow gadgets blog posts will continue in 2007 and so far you can read parts one, two, three, four and five.
09. I spent 6 months last year focusing almost entirely on Vista developer features that are new and that are *not* part of NetFx3. I have catalogued my blogging & screencasting efforts in a large collection of links to content that supports my speaking engagements on Vista. IMO this blog post alone could have been the best of "The Moth" this year:
The year of 2006 I made 142 blog entries and below are a select few. Happy New Year!
01. I didn't have a chance to play with it as much as I wanted to, but with very little public info available, this blog served it well: .NET Micro Framework, its product sheet and other NETMF links.
02. Recognising an idiom of the using statement.
03. A cute desktop feature implemented for the Windows Mobile/WinCE platform in a reusable NETCF control: TextBox cue banner.
04. A picture is worth a 100 words and a video is... a whole bunch of pictures! Check mine out following the instructions here for my nuggets.
05. A comprehensive collection of links for Windows Workflow Foundation (WF).
06. I collected the links to my 9 blog posts on sharing assets between desktop and mobile platforms in one place. Follow the numbered links.
07. The most controversial feature of Windows Vista is something every developer must understand: User Account Control.
08. One of Vista's features is becoming my obsession and that is SideShow. My series of SideShow gadgets blog posts will continue in 2007 and so far you can read parts one, two, three, four and five.
09. I spent 6 months last year focusing almost entirely on Vista developer features that are new and that are *not* part of NetFx3. I have catalogued my blogging & screencasting efforts in a large collection of links to content that supports my speaking engagements on Vista. IMO this blog post alone could have been the best of "The Moth" this year:
Vista-only features for the managed developer.Stay tuned in 2007 via one of the subscribe options on the left :-)
Labels: dot NET general, Links, Mobile and Embedded, Vista
# posted by The Moth @ 6:56:00 AM
Thursday, December 28, 2006
There is a NETMF book on the horizon and check out its very own book website (thanks Mike for the heads-up).
NETMF also gains its own NETMF MSDN area :-)
NETMF also gains its own NETMF MSDN area :-)
Labels: Mobile and Embedded
# posted by The Moth @ 8:05:00 AM
Tuesday, December 26, 2006
Remember the problem I got when trying to deploy to a real device from VS2005 on Vista? As that blog entry says, the solution was to run VS elevated once and that rectified the issue.
On an internal list I noticed someone else had a device issue on Vista this time with Platform Builder 6.0 and their error apparently was:
PB Debugger Warning: Debugger service map is set to none. If your image has debugging support it may not boot properly
...guess what the solution was again? Correct, run VS elevated once.
The other day at an offsite I did a very short intro to Windows Mobile development so I wanted to show first a small desktop app, then the same code in a device project connecting to a device and then connecting to an emulator. I prepared the machine before the short presentation by running VS normally for the desktop project and then running another instance elevated for the device project. I also wanted to save time by launching the emulator ready to use, so I did that from the VS menu and the first instance of VS that I came across was the desktop project. Can you spot the mistake I made?
When later in the presentation I tried to connect from the device project to the emulator I was treated to this:
The moral of the story: You cannot have an elevated VS instance talking to a non-elevated emulator.
On an internal list I noticed someone else had a device issue on Vista this time with Platform Builder 6.0 and their error apparently was:
PB Debugger Warning: Debugger service map is set to none. If your image has debugging support it may not boot properly
...guess what the solution was again? Correct, run VS elevated once.
The other day at an offsite I did a very short intro to Windows Mobile development so I wanted to show first a small desktop app, then the same code in a device project connecting to a device and then connecting to an emulator. I prepared the machine before the short presentation by running VS normally for the desktop project and then running another instance elevated for the device project. I also wanted to save time by launching the emulator ready to use, so I did that from the VS menu and the first instance of VS that I came across was the desktop project. Can you spot the mistake I made?
When later in the presentation I tried to connect from the device project to the emulator I was treated to this:
---------------------------Cryptic or what? The solution of course was to shut down the emulator and this time launch it from the elevated VS instance.
Device Emulator
---------------------------
Error: The current VMID is in use. Wait for the other application to exit.
---------------------------
OK
---------------------------
The moral of the story: You cannot have an elevated VS instance talking to a non-elevated emulator.
Labels: Mobile and Embedded
# posted by The Moth @ 6:07:00 PM
Friday, December 22, 2006
I hope by now everyone has heard about the XNA Framework, a set of managed code libraries for writing games on the Xbox and the PC.
Not everyone will know that the engine in XNA is based on the CLR of the .NET Compact Framework (I first heard about it here). What this could mean to device developers is that the next version of the NETCF has even more performance improvements (wouldn’t you back port any perf changes you made ;-)).
Existing NETCF application developers are prime candidates for becoming good XNA game developers (assuming you are not graphically challenged like me!). For those of you that haven’t dabbled with the NETCF before, learn how to write XNA code that performs well and read these 2 fresh posts by Chris To of the NETCF team: Part 1, Part 2.
Not everyone will know that the engine in XNA is based on the CLR of the .NET Compact Framework (I first heard about it here). What this could mean to device developers is that the next version of the NETCF has even more performance improvements (wouldn’t you back port any perf changes you made ;-)).
Existing NETCF application developers are prime candidates for becoming good XNA game developers (assuming you are not graphically challenged like me!). For those of you that haven’t dabbled with the NETCF before, learn how to write XNA code that performs well and read these 2 fresh posts by Chris To of the NETCF team: Part 1, Part 2.
Labels: Mobile and Embedded
# posted by The Moth @ 5:00:00 PM
Tuesday, November 28, 2006
In the presentation to students that I mentioned here, I thought it was essential to show the smart device project deploy to the actual device (rather than the emulator that I use almost exclusively nowadays) since for newbies to the dev experience, I think it adds a lot of value to see that "this stuff is real".
When prepping for the event I realised that deploying to the device (and not the emulator) was broken on Vista! The error shown in the Error List was:
the required ActiveSync proxy ports are not registered
...this came from the Device Connectivity Component
I had heard the rumour that there are issues with VS2005 development on Vista but other than the one I talked about here, I had never faced *any* issues so this was a first for me! Luckily someone from the VSD team was able to give me a virtual slap and remind me that I should dogfood the workarounds we give to the public: Run VS2005 elevated – doh! I have never had to do that to date... Luckily I received this advice before my presentation earlier today :-)
Blogging this in case anyone else faces this issue (surprisingly no search results for the error above). If you are running WMDC on Vista RTM with VS2005 (without SP1) and you get the error above, run VS elevated (right click and select “Run as administrator”) and the issue goes away... phew!
For other device development issues on Vista see the relevant VSD blog entry.
When prepping for the event I realised that deploying to the device (and not the emulator) was broken on Vista! The error shown in the Error List was:
the required ActiveSync proxy ports are not registered
...this came from the Device Connectivity Component
I had heard the rumour that there are issues with VS2005 development on Vista but other than the one I talked about here, I had never faced *any* issues so this was a first for me! Luckily someone from the VSD team was able to give me a virtual slap and remind me that I should dogfood the workarounds we give to the public: Run VS2005 elevated – doh! I have never had to do that to date... Luckily I received this advice before my presentation earlier today :-)
Blogging this in case anyone else faces this issue (surprisingly no search results for the error above). If you are running WMDC on Vista RTM with VS2005 (without SP1) and you get the error above, run VS elevated (right click and select “Run as administrator”) and the issue goes away... phew!
For other device development issues on Vista see the relevant VSD blog entry.
Labels: Mobile and Embedded
# posted by The Moth @ 9:42:00 AM
Wednesday, November 15, 2006
Ignore if you are not into embedded stuff. If you are, you heard it here first :-).
In the past I've talked about NETMF, and now you can download the product sheet here.
In the past I've talked about NETMF, and now you can download the product sheet here.
Labels: Mobile and Embedded
# posted by The Moth @ 1:21:00 PM
Tuesday, October 31, 2006
When we talk about the NetFx3 technologies, there are always one or two attendees (not the same ones each time!) that ask if any of the technologies are applicable to mobile devices. There are no plans for WF and no immediate plans for WPF (often confused with WPF/e which is actually quite a different technology with an unfortunate name IMO).
However, the WCF story is good with Orcas and it is now public information! Read all about the WCF support on Roman's blog post. Below some choice quotes:
Go read the full story!
However, the WCF story is good with Orcas and it is now public information! Read all about the WCF support on Roman's blog post. Below some choice quotes:
"... The WCF programming model support will be limited to channel layer messaging (no service model support on the device) [...]
[...] We'll expose all necessary extensibility points so people could plug in their own transport and layered channels, while maintaining a unified programming model. [...] The channels we plan to deliver out of the box are Http and... yes, e-mail (for WCF on desktop and device)."
Go read the full story!
Labels: Mobile and Embedded
Monday, October 09, 2006
Remember that rss download feed I was telling you about? It just "dropped me a line" to say that all the MEDC content is available for anyone to download!
Go get the MEDC 2006 conference DVD!
My session was APP330...
Go get the MEDC 2006 conference DVD!
My session was APP330...
Labels: Mobile and Embedded
Saturday, October 07, 2006
I promised I’d let you know when WMDC for RC1 was out. Also given that most people searching for an ActiveSync replacement or for Windows Mobile Device Centre land on my blog, it is only fair that I let you have some links!
WMDC Beta3 page here. (Notice how now there is also support for Windows Mobile 2003 :))
How did I know? I got notified via the download center RSS feed (don’t tell me you are not subscribed to that?!) about the download page.
WMDC Beta3 page here. (Notice how now there is also support for Windows Mobile 2003 :))
How did I know? I got notified via the download center RSS feed (don’t tell me you are not subscribed to that?!) about the download page.
Labels: Mobile and Embedded
Tuesday, October 03, 2006
A topic I've done a lot of work on in the past and just one of the areas covered in Nick Randolph's podcast so go listen here (funny American and Aussie accents aside :-p).
Inspired by the podcast, I gathered some of the relevant blog posts I've written on the subject in chronological order (click on the numbers): 1, 2, 3, 4, 5, 6, 7, 8, 9
Favourite quote by Nick near the end (47:51):
Microsoft Developer Show #8
Inspired by the podcast, I gathered some of the relevant blog posts I've written on the subject in chronological order (click on the numbers): 1, 2, 3, 4, 5, 6, 7, 8, 9
Favourite quote by Nick near the end (47:51):
"...you need the equivalent of the vb6 to vb.net converter/wizard... you'd run it on a VB6 app and it would come back with 18 million lines of code that had to be changed and your application only had 500K lines of code! "LOL... been there, done that, got the t-shirt :D
Microsoft Developer Show #8
Labels: Mobile and Embedded
Saturday, September 30, 2006
Over the last year I have had a few people contact me with questions relating to the Point to Point Message Queue class I wrote for MSDN. This blog entry will serve as a URL where I can point future questions regarding it.
1. It seems that under certain circumstances, on certain platforms, the queue does not close properly. A possible solution is to declare a dedicated named event that you create in the ctor of the queue. Set it in the
2. It also seems that under certain other conditions (that amongst other things include multiple senders) the class spikes the cpu. This is due to the way the native API works and the solution is not to run the thread that is responsible for raising events. To do that, follow the advice of the article and create a new P2PMessageQueueSender class that inherits from the original one and simply overrides the
3. If you are porting the code to NETCF v2.0 (when I wrote the article it wasn’t released yet), there are things you can do to the code other than simply recompiling it, such as making any worker threads to background (IsBackground=true) .
Of course, the easiest thing for you to do is none of the above. Simply get the SDF from OpenNETCF, which will include the above improvements (plus you can then get support from the team as opposed to the “as is” code of my old msdn article ;-)).
For other NETCF questions, please use the newsgroup and forum...
1. It seems that under certain circumstances, on certain platforms, the queue does not close properly. A possible solution is to declare a dedicated named event that you create in the ctor of the queue. Set it in the
Close method. In the Monitor method, change the WaitForSingleObject to WaitForMultipleObjects and include this new event.2. It also seems that under certain other conditions (that amongst other things include multiple senders) the class spikes the cpu. This is due to the way the native API works and the solution is not to run the thread that is responsible for raising events. To do that, follow the advice of the article and create a new P2PMessageQueueSender class that inherits from the original one and simply overrides the
StartEventThread with an empty method (Note that this solution should also work for the 1st issue described above)3. If you are porting the code to NETCF v2.0 (when I wrote the article it wasn’t released yet), there are things you can do to the code other than simply recompiling it, such as making any worker threads to background (IsBackground=true) .
Of course, the easiest thing for you to do is none of the above. Simply get the SDF from OpenNETCF, which will include the above improvements (plus you can then get support from the team as opposed to the “as is” code of my old msdn article ;-)).
For other NETCF questions, please use the newsgroup and forum...
Labels: Mobile and Embedded
Friday, September 22, 2006
I followed the launch link from Mike's blog and, unless I am reading too much into it, the official product name for the next version of Windows CE is... (drum roll)...
Windows Embedded CE 6.0
Labels: Mobile and Embedded
Thursday, September 21, 2006
At most of my sessions on Vista I make the assertion that everyone has switched to .NET 2.0 and usually I get everybody nodding, but last week someone said:
"No, because it is not supported on Windows XP embedded".
I didn't know that at the time, but looking at the fountain of all knowledge (aka MSDN) I found this download that contradicts that statement: .NET 2.0 for XPe
While following links from the XPe site I also found a chat from a month ago about the longest product name ever:
"Windows XP Embedded Service Pack 2 Feature Pack 2007 Community Technology Preview"
What makes it even funnier is that besides the "2007" in its title, it is actually scheduled for release this year :-))
"No, because it is not supported on Windows XP embedded".
I didn't know that at the time, but looking at the fountain of all knowledge (aka MSDN) I found this download that contradicts that statement: .NET 2.0 for XPe
While following links from the XPe site I also found a chat from a month ago about the longest product name ever:
"Windows XP Embedded Service Pack 2 Feature Pack 2007 Community Technology Preview"
What makes it even funnier is that besides the "2007" in its title, it is actually scheduled for release this year :-))
Labels: Mobile and Embedded
Thursday, September 14, 2006
If you missed my session at MEDC, I'll be doing a repeat online for the Windows Virtual Mobile Group next Wednesday 20th September (12:00AM Eastern Time, 17:00 GMT)
Register Now!
I’ll be assuming knowledge of device development of course so if you are a desktop developer, get started ;-)
Register Now!
I’ll be assuming knowledge of device development of course so if you are a desktop developer, get started ;-)
Labels: Mobile and Embedded
Thursday, September 07, 2006
No, it is not out for public consumption yet (although it is running here on my laptop). I was going to write an explanation to address the WMDC confusion... but Mel beat me to it here.
Labels: Mobile and Embedded
Tuesday, August 08, 2006
For all my mobility developer friends, just got word that there is a new resource where you can get and contribute information regarding the Mobile Client Software Factory.
I then looked at Eugenio's latest blog entry and found a sea of resources: bookmarked!
I then looked at Eugenio's latest blog entry and found a sea of resources: bookmarked!
Labels: Mobile and Embedded
Thursday, July 13, 2006
When talking about TextBox with cue banner I thought I had done a good job at the end of the post of hinting that someone should write a pure managed version; a version that is not restricted to Windows Vista, but rather would work on WindowsCE/WindowsMobile devices (via the .NET Compact Framework of course).
Since nobody stepped up, I thought I'd tackle it myself :-). I have to say that what I thought would be a 10 minute job ended up taking 6 times as long and right about now I give up as what I have is good enough and a nice starter for someone else to take and polish, iron out any issues etc.
So, with no pinvokes and explicitly tested on WM 5.0 and WinXP, here is the TextBoxWithPrompt code file. Simply save this file and add it to one of your projects and then build all. Now open a form and go to the toolbox where you can drag the TextBoxWithPrompt onto your form and change its
As always feel free to contact me via the link on the left about my blog entries.
Since nobody stepped up, I thought I'd tackle it myself :-). I have to say that what I thought would be a 10 minute job ended up taking 6 times as long and right about now I give up as what I have is good enough and a nice starter for someone else to take and polish, iron out any issues etc.
So, with no pinvokes and explicitly tested on WM 5.0 and WinXP, here is the TextBoxWithPrompt code file. Simply save this file and add it to one of your projects and then build all. Now open a form and go to the toolbox where you can drag the TextBoxWithPrompt onto your form and change its
TextPrompt property to e.g. “Enter your name”As always feel free to contact me via the link on the left about my blog entries.
Labels: Mobile and Embedded
Sunday, July 09, 2006
Thank you all that attended my webcast.
For those that missed it, you can replay it here: .NET Compact Framework for Desktop developers. You get the same experience except slide animations seem to have been taken out and of course you can't interact and ask questions.
Speaking of questions, looks like my content was so clear that I didn’t have to clarify anything :-p. Instead, here are some of the questions that I received.
Q1) I see from one of the last slides that you won't be covering SQL CE/SQL Mobile/SQL Everywhere. Please consider doing so in a future webcast.
A1) Thank you for the suggestion. In the mean time you can find info on SQL Everywhere here and here. Ask questions on this topic here.
Q2) Does Groove offer support for mobile devices yet?
A2) I have absolutely no idea. I would think not and indeed searching seems to bring back no relevant results so I'll stick with "no it is not supported at the moment" guess. If anyone has info to the contrary please enlighten me and I'll update this. Groove home page.
Q3) Are there any particularly cool open source projects for Windows Mobile?
A3) Yes, SDF from OpenNETCF. Source for v1.x is free and for v2.x available at a small fee. Binaries are free regardless of version.
Q4) What's your initial opinion of the new Mobile Client Software Factory? Is it useful for beginners or should novices focus on more meat and potatoes issues?
A4) I think it is a great effort. As everything else, only you know if it is of value for your particular scenario but definitely do check it out.
Q5) Windows Mobile or Tablet PCs?
A5) Mobility development is a wide field from laptops to tabletpcs to UMPCs to PocketPCs to Smartphones to watches! Depending on the job requirements one or more of the previous platforms can be chosen for any particular project. There is no universal answer.
Expect to read more on this blog soon regarding the Vista mobility story
Q6) Mapping for devices?
A6) See this and this. I would expect this to fully support mobile browsers or someone will be missing a trick.
Q7) In some Windows Mobile devices the .Net Compact Framework is in the system ROM in others it has to be downloaded and installed, what is the performance and other impacts of the built in framework vs a downloaded version?
A7) If you are building against a NETCF version that you expect to be in ROM on all your target devices, then there is no issue. If you don't, then you need to deploy the NETCF runtime with your app. In that case, NETCF is installed in RAM and hence using some of it (much like installing any application on your device). The other difference between the NETCF being in RAM or ROM is a tiny perf advantage in the ROM case. This is not something you should be worried about as it will definitely not be your perf bottleneck if you have one.
For those that missed it, you can replay it here: .NET Compact Framework for Desktop developers. You get the same experience except slide animations seem to have been taken out and of course you can't interact and ask questions.
Speaking of questions, looks like my content was so clear that I didn’t have to clarify anything :-p. Instead, here are some of the questions that I received.
Q1) I see from one of the last slides that you won't be covering SQL CE/SQL Mobile/SQL Everywhere. Please consider doing so in a future webcast.
A1) Thank you for the suggestion. In the mean time you can find info on SQL Everywhere here and here. Ask questions on this topic here.
Q2) Does Groove offer support for mobile devices yet?
A2) I have absolutely no idea. I would think not and indeed searching seems to bring back no relevant results so I'll stick with "no it is not supported at the moment" guess. If anyone has info to the contrary please enlighten me and I'll update this. Groove home page.
Q3) Are there any particularly cool open source projects for Windows Mobile?
A3) Yes, SDF from OpenNETCF. Source for v1.x is free and for v2.x available at a small fee. Binaries are free regardless of version.
Q4) What's your initial opinion of the new Mobile Client Software Factory? Is it useful for beginners or should novices focus on more meat and potatoes issues?
A4) I think it is a great effort. As everything else, only you know if it is of value for your particular scenario but definitely do check it out.
Q5) Windows Mobile or Tablet PCs?
A5) Mobility development is a wide field from laptops to tabletpcs to UMPCs to PocketPCs to Smartphones to watches! Depending on the job requirements one or more of the previous platforms can be chosen for any particular project. There is no universal answer.
Expect to read more on this blog soon regarding the Vista mobility story
Q6) Mapping for devices?
A6) See this and this. I would expect this to fully support mobile browsers or someone will be missing a trick.
Q7) In some Windows Mobile devices the .Net Compact Framework is in the system ROM in others it has to be downloaded and installed, what is the performance and other impacts of the built in framework vs a downloaded version?
A7) If you are building against a NETCF version that you expect to be in ROM on all your target devices, then there is no issue. If you don't, then you need to deploy the NETCF runtime with your app. In that case, NETCF is installed in RAM and hence using some of it (much like installing any application on your device). The other difference between the NETCF being in RAM or ROM is a tiny perf advantage in the ROM case. This is not something you should be worried about as it will definitely not be your perf bottleneck if you have one.
Labels: Mobile and Embedded
Friday, June 30, 2006
It seems many NETCF developers are being bitten on Windows Vista after installing the WM 5.0 SDK for Visual Studio. The symptom is that although the SDK installation appears to go fine, the WM 5.0 project templates do not appear in VS2005.
The problem has to do with User Account Control (btw, I'll have a lot more to say about UAC in a future blog post). The way to work around it (on Vista Beta 2 at least) is to disable UAC and then install the WM 5.0 SDK thus getting the project templates to appear.
Specifically:
1. Launch "Control Panel"
2. Navigate to "User Accounts and Family Safety -> User Accounts"
3. Click on "Change Security Settings"
4. On the window that appears, uncheck the "Use User Account Control (UAC) to help protect your computer" checkbox (requires restart)
5. Now install the WM 5.0 SDK (or do a repair if you already had)
6. Launch VS2005 to verify you have the templates
7. Enable UAC again
The above combined with the WMDC update should answer most relevant queries...
The problem has to do with User Account Control (btw, I'll have a lot more to say about UAC in a future blog post). The way to work around it (on Vista Beta 2 at least) is to disable UAC and then install the WM 5.0 SDK thus getting the project templates to appear.
Specifically:
1. Launch "Control Panel"
2. Navigate to "User Accounts and Family Safety -> User Accounts"
3. Click on "Change Security Settings"
4. On the window that appears, uncheck the "Use User Account Control (UAC) to help protect your computer" checkbox (requires restart)
5. Now install the WM 5.0 SDK (or do a repair if you already had)
6. Launch VS2005 to verify you have the templates
7. Enable UAC again
The above combined with the WMDC update should answer most relevant queries...
Labels: Mobile and Embedded
Tuesday, June 27, 2006
Some people are asking about NETCF on Symbian. This makes me smile.
You see, every now and then, someone will bring out a Nokia phone and show me some end user feature and ask me how to achieve the same on a Windows Mobile device following it with a rant about how Symbian devices are dominant in the market compared to WM devices. My response is always the same. Yes, at the moment, Symbian is the dominant mobile OS when it comes to number of end user devices out there (not so sure in the enterprise/corporate world). However, from a developer perspective, that is completely irrelevant! Ask not how many devices are out there, ask how many of them are running an app that did not ship with the device. In other words, ask what percentage of Symbian devices compared to WM devices are running a 3rd party application that the user installed themselves. Windows Mobile *is* the dominant OS when you ask the right question and it is kind of expectant really: Every windows developer is a potential WM developer. The platform itself is built with running 3rd party apps in mind.
So going back to the original question, it shouldn't surprise us that it is being posed. An unfortunate developer has been asked by a decision maker to target a Symbian device and naturally the developer wants to use a modern, RAD and powerful platform.
The best development tool for all your needs is of course Visual Studio. To that end, there is an add-in for Visual Studio that allows targeting non-WM devices BUT note that this does not use the NETCF on the target - it is just a tool thing.
The best development runtime/framework of course is the .NET Compact Framework (ok, so I may be slightly biased :-)). When I was at MEDC a South African guy (Dusan Babich) approached me with some brochures and interesting ideas about porting the NETCF to a subset of Symbian devices. He didn't have a demo to show at the time but he said they were very close to releasing. I am not sure how far it got but this is their website should you wish to follow up.
I also found this excellent paper on porting the NETCF to Symbian phones. Just to keep the balance, here is an article on porting Symbian apps to Windows Mobile SmartPhones.
So there you have it. A slightly lengthier reply than what I had in mind originally but it is good to have context, right? To wrap it up, my advice is to target the Windows Mobile platform that gives you a versatile range of devices with a common API (and the story will get even better with future versions of SmartPhone and PPC form factors converging, I would imagine). If I am perfectly honest, I am not sure WM will win the consumer market tomorrow, but it is definitely slashing into the enterprise space right now and once it is done there, more of an end user focus should follow, in my opinion.
You see, every now and then, someone will bring out a Nokia phone and show me some end user feature and ask me how to achieve the same on a Windows Mobile device following it with a rant about how Symbian devices are dominant in the market compared to WM devices. My response is always the same. Yes, at the moment, Symbian is the dominant mobile OS when it comes to number of end user devices out there (not so sure in the enterprise/corporate world). However, from a developer perspective, that is completely irrelevant! Ask not how many devices are out there, ask how many of them are running an app that did not ship with the device. In other words, ask what percentage of Symbian devices compared to WM devices are running a 3rd party application that the user installed themselves. Windows Mobile *is* the dominant OS when you ask the right question and it is kind of expectant really: Every windows developer is a potential WM developer. The platform itself is built with running 3rd party apps in mind.
So going back to the original question, it shouldn't surprise us that it is being posed. An unfortunate developer has been asked by a decision maker to target a Symbian device and naturally the developer wants to use a modern, RAD and powerful platform.
The best development tool for all your needs is of course Visual Studio. To that end, there is an add-in for Visual Studio that allows targeting non-WM devices BUT note that this does not use the NETCF on the target - it is just a tool thing.
The best development runtime/framework of course is the .NET Compact Framework (ok, so I may be slightly biased :-)). When I was at MEDC a South African guy (Dusan Babich) approached me with some brochures and interesting ideas about porting the NETCF to a subset of Symbian devices. He didn't have a demo to show at the time but he said they were very close to releasing. I am not sure how far it got but this is their website should you wish to follow up.
I also found this excellent paper on porting the NETCF to Symbian phones. Just to keep the balance, here is an article on porting Symbian apps to Windows Mobile SmartPhones.
So there you have it. A slightly lengthier reply than what I had in mind originally but it is good to have context, right? To wrap it up, my advice is to target the Windows Mobile platform that gives you a versatile range of devices with a common API (and the story will get even better with future versions of SmartPhone and PPC form factors converging, I would imagine). If I am perfectly honest, I am not sure WM will win the consumer market tomorrow, but it is definitely slashing into the enterprise space right now and once it is done there, more of an end user focus should follow, in my opinion.
Labels: Mobile and Embedded
Friday, June 16, 2006
There was a pleasant surprise on Windows Update this morning, a Beta update of the Windows Mobile Device Center that I talked about last month. After downloading it I captured some screenshots below (some are behind the hyperlinks and others inline with the body).
First connect a WM device or you'll get different screenshots since the UI options are visible only when applicable.
First screen offers us two options. The first one sets up the partnership and the second looks like this:
Hovering over any of the 4 areas, exposes further options: Programs and Services, Pictures Music and Video, File Management and Mobile Device Settings.
The Programs and Services option has two sub-options: One takes you to the windowsmobile home page on microsoft.com; the other option allows you to add/remove programs via this dialog:
The Pictures Music and Video option has 3 sub-options: one shows you how many "new pictures/video clips are available for import"; the last one launches a wizard from Media Player so you can "add media to your device from windows media player"; the middle option offers the following dialog "picture video import settings":
The File Management option doesn't seem to have changed from the one I captured last time.
The Mobile Device Settings option shows connection settings and of course the one we've all been waiting for: Setting up partnership (which I'll have more on later :-)
First connect a WM device or you'll get different screenshots since the UI options are visible only when applicable.
First screen offers us two options. The first one sets up the partnership and the second looks like this:
Hovering over any of the 4 areas, exposes further options: Programs and Services, Pictures Music and Video, File Management and Mobile Device Settings.
The Programs and Services option has two sub-options: One takes you to the windowsmobile home page on microsoft.com; the other option allows you to add/remove programs via this dialog:
The Pictures Music and Video option has 3 sub-options: one shows you how many "new pictures/video clips are available for import"; the last one launches a wizard from Media Player so you can "add media to your device from windows media player"; the middle option offers the following dialog "picture video import settings":
The File Management option doesn't seem to have changed from the one I captured last time.
The Mobile Device Settings option shows connection settings and of course the one we've all been waiting for: Setting up partnership (which I'll have more on later :-)
Labels: Mobile and Embedded
Wednesday, May 24, 2006
Click on the links in this post to unveil the screenshots
Plug your Windows Mobile device to your Vista machine, and you get greeted by Windows Mobile Device Center.
If you click on "Pictures, Music and Video" then you'll get Media Player with the option to sync media.
Clicking on "File Management" brings up Portable Devices in explorer, allowing you to transfer files between the device and computer. On my device I have a 2GB SD card, so explorer shows that too. Another way of arriving to a similar display is simply by browsing Computer (no longer called My Computer).
The 3rd and final option of Mobile Device Center is "Change PC and connection settings".
By the way, if you don't plug a device and you want to view the Mobile Device Center window (or if you close the window and want to get it back), finding it is not easy. First I opened the "Control Panel" and naively thought it would be under "Mobile PC". I tried the "Mobility Center" but no luck there either. Finally, I found it under "Additional Options".
So, to sum up, the great news is that Vista has the *base* functionality of ActiveSync built in. The bad news is that (in build 5384 at least) not all the features of ActiveSync are available (plus AS isn't supported on Vista).
To finish on a positive note, by Vista RTM the Windows Mobile Device Center base application (probably complemented by a supplement) *will* completely replace ActiveSync. At that point we'll be able to target a real device from VS2005 for NETCF development!
UPDATE WMDC is here!
Plug your Windows Mobile device to your Vista machine, and you get greeted by Windows Mobile Device Center.
If you click on "Pictures, Music and Video" then you'll get Media Player with the option to sync media.
Clicking on "File Management" brings up Portable Devices in explorer, allowing you to transfer files between the device and computer. On my device I have a 2GB SD card, so explorer shows that too. Another way of arriving to a similar display is simply by browsing Computer (no longer called My Computer).
The 3rd and final option of Mobile Device Center is "Change PC and connection settings".
By the way, if you don't plug a device and you want to view the Mobile Device Center window (or if you close the window and want to get it back), finding it is not easy. First I opened the "Control Panel" and naively thought it would be under "Mobile PC". I tried the "Mobility Center" but no luck there either. Finally, I found it under "Additional Options".
So, to sum up, the great news is that Vista has the *base* functionality of ActiveSync built in. The bad news is that (in build 5384 at least) not all the features of ActiveSync are available (plus AS isn't supported on Vista).
To finish on a positive note, by Vista RTM the Windows Mobile Device Center base application (probably complemented by a supplement) *will* completely replace ActiveSync. At that point we'll be able to target a real device from VS2005 for NETCF development!
UPDATE WMDC is here!
Labels: Mobile and Embedded
Thursday, May 18, 2006
I hope those of you at MEDC caught Barry Bond's session on the emulator. Well, it is now RTM :-)
Download it now
The Microsoft Device Emulator 1.0 is a standalone version of the same ARM based Device Emulator that ships as part of Visual Studio 2005. The standalone emulator is intended for situations when you want to demonstrate or test your application on a computer that does not have Visual Studio 2005 installed. In addition, we are offering the Windows Mobile 5.0 and Windows Mobile 2003 SE operating system images that you can use with the Device Emulator.
Device Emulator 1.0 has a number of features that make it significantly better than its predecessor (the x86 emulator). You will find that it:
* Runs code compiled for ARM processors rather than for x86 processors. In most cases, you can run the same binaries on the emulator as you do on the device.
* Supports synchronizing with ActiveSync. You can use the Device Emulator with a full ActiveSync partnership. This feature allows you to debug applications that are syncing, or be able to use real synchronized data from within the Device Emulator.
* Provides support for more development environments. The emulator has been tested for developing and debugging applications with Visual Studio 2005, Visual Studio .NET 2003, and with eMbedded Visual C++ 4.0 (eVC4) SP4, all using ActiveSync. No crossover serial cable is required.
* The Device Emulator supports GAPI. You can write and debug GAPI games on the Device Emulator and expect them to work.
Download it now
Labels: Mobile and Embedded
Wednesday, May 17, 2006
FYI, John Kennedy (whom I had the chance to meet at MEDC and he is a fine example of a British character :-) updated the mobile wiki with a list of Windows Mobile 5.0 AKUs
...and for my non-mobility readers who are wondering what it is: AKU
...and for my non-mobility readers who are wondering what it is: AKU
Labels: Mobile and Embedded
Saturday, May 13, 2006
I hinted before that this would be one of the big announcements at MEDC 2006, and I wasn't far off.
At the high level, here is what I recall about it:
1. Evolution of the SPOT. Has tiny footprint (200-400 KB), about ~1MB of flash required and very low power consumption.
2. Ships with Watches, Microsoft TV, Vista SideShow and plans for many more internally and many partners already on board.
3. Targets platforms smaller than WinCE (and thus smaller than WinPX embedded, of course) such as Sensors, actuators, remote controls, wearable devices etc.
4. Bootable .NET runtime (i.e. this is not an application layer on top of the core platform... it *is* the platform) including managed drivers!
5. C# only, interpreted. Program via Visual Studio 2005, naturally :-)
6. ARM 7, ARM 9 only (no MMU).
7. 100-150 APIs is all an OEM/ODM needs to implement for supporting /porting/integrating the platform.
8. No Windows Forms, but if you include the UI/Shell, it is based on WPF - hope the NETCF team can take a leaf out of the NETMF book cause Avalon and XAML rock (I suspect I’ll be blogging about that more in the future)!
9. SumoBot competition at MEDC was based on this. I wrote some of our NETMF code for our bot (we lost in the first round... hmm...).
At the high level, here is what I recall about it:
1. Evolution of the SPOT. Has tiny footprint (200-400 KB), about ~1MB of flash required and very low power consumption.
2. Ships with Watches, Microsoft TV, Vista SideShow and plans for many more internally and many partners already on board.
3. Targets platforms smaller than WinCE (and thus smaller than WinPX embedded, of course) such as Sensors, actuators, remote controls, wearable devices etc.
4. Bootable .NET runtime (i.e. this is not an application layer on top of the core platform... it *is* the platform) including managed drivers!
5. C# only, interpreted. Program via Visual Studio 2005, naturally :-)
6. ARM 7, ARM 9 only (no MMU).
7. 100-150 APIs is all an OEM/ODM needs to implement for supporting /porting/integrating the platform.
8. No Windows Forms, but if you include the UI/Shell, it is based on WPF - hope the NETCF team can take a leaf out of the NETMF book cause Avalon and XAML rock (I suspect I’ll be blogging about that more in the future)!
9. SumoBot competition at MEDC was based on this. I wrote some of our NETMF code for our bot (we lost in the first round... hmm...).
Labels: Mobile and Embedded
Monday, May 08, 2006
Today (Monday) I registered for the MEDC at the Venetian (remember to come to my session if you are here tomorrow Tuesday at 16:45) where I received my bag and badge.
Looking at the contents of the bag, gives away some of the themes of this year's conference (if they weren't obvious already).
* Windows CE 6 Beta DVDs
On the inside cover it reads: "Windows CE 6 features a redesigned kernel architecture that supports up to 32767 simultaneous processes and 2 GB virtual address space per process"
...then under Disc 2 it reads: "...with Platform Builder Plug-in for Visual Studio 2005" :-)
* The t-shirt
It is about the .NET Micro Framework pointing to aboutnetmf.com
* Two pairs of Windows Mobile 5.0 DVDs
The "Windows Mobile 5.0 Developer Resource Kit" and the cool new "Windows Mobile Enterprise Resource Kit"
Also in the bag:
- 8 marketing brochures including one from OpenNETCF
- A notepad, conference guide and hard copy of "Smartphone and Pocket PC" mag
- A jelly cell mate
I don't like this year's bag so I will be going round with last year's bag, since my laptop fits in it this time!
Looking at the contents of the bag, gives away some of the themes of this year's conference (if they weren't obvious already).
* Windows CE 6 Beta DVDs
On the inside cover it reads: "Windows CE 6 features a redesigned kernel architecture that supports up to 32767 simultaneous processes and 2 GB virtual address space per process"
...then under Disc 2 it reads: "...with Platform Builder Plug-in for Visual Studio 2005" :-)
* The t-shirt
It is about the .NET Micro Framework pointing to aboutnetmf.com
* Two pairs of Windows Mobile 5.0 DVDs
The "Windows Mobile 5.0 Developer Resource Kit" and the cool new "Windows Mobile Enterprise Resource Kit"
Also in the bag:
- 8 marketing brochures including one from OpenNETCF
- A notepad, conference guide and hard copy of "Smartphone and Pocket PC" mag
- A jelly cell mate
I don't like this year's bag so I will be going round with last year's bag, since my laptop fits in it this time!
Labels: Mobile and Embedded
Sunday, April 30, 2006
Recently I opened a VS2005 Smart Device project that I was assured worked for others, only to face an error message box:
When I hit my only choice, which was the OK button, a warning message box appeared:
Clicking OK or Cancel had the same effect: the project does not load (i.e. it is "unavailable" in solution explorer).
However, in the top right corner of the warning message box there was the question mark icon. At first I didn't think of clicking on it, since it traditionally is used to get help on UI widgets on the dialog box it appears on. Instead, this one acted as a Help button (why not offer that next to the Cancel button is beyond me) and pointed to this msdn page:
So clearly whoever saved that project had saved it while the "Target Device" was set to "Windows Mobile 5.0" (and probably created the project in the first place by choosing the WM 5.0 template). Since the WM 5.0 SDK doesn't ship with VS2005, any machine (like my tablet) that hasn't had the WM 5.0 SDK installed fails to open the project.
As I didn't have time at this instance to download the SDK (or switch to my main machine that has the SDK installed), I opened the csproj file in notepad, located the following line:
<PlatformID>4118C335-430C-497f-BE48-11C3316B135E</PlatformID>
... and changed it to this one:
<PlatformID>3C41C503-53EF-4c2a-8DD4-A8217CAD115E</PlatformID>
Save and close, now reopen in Visual Studio and all is fine (with Target Device set to "Pocket PC 2003").
While it makes no difference, I also changed the OSVersion tag, since it points to 5.01, which is not the WinCE version that PPC2003 is based on: 4.20
Finally note that if you *can* open your project and *then* need to change the platform, you don't have to mess with the text files, simply choose Project->Change Target Platform.
---------------------------
Microsoft Visual Studio
---------------------------
Error retrieving information from user datastore. Platform not found.
---------------------------
OK
---------------------------
When I hit my only choice, which was the OK button, a warning message box appeared:
---------------------------
Microsoft Visual Studio
---------------------------
The project could not be opened because it refers to a device platform that does not exist in your datastore.
---------------------------
OK Cancel
---------------------------
Clicking OK or Cancel had the same effect: the project does not load (i.e. it is "unavailable" in solution explorer).
However, in the top right corner of the warning message box there was the question mark icon. At first I didn't think of clicking on it, since it traditionally is used to get help on UI widgets on the dialog box it appears on. Instead, this one acted as a Help button (why not offer that next to the Cancel button is beyond me) and pointed to this msdn page:
The project you are trying to load targets a device platform that your Visual Studio installation is not configured to support.
To correct this error
Install the platform that supports the project you want to load.
For example if you are trying to load a Windows Mobile 5.0 project and do not have the Windows Mobile 5.0 SDK installed, install the Windows Mobile 5.0 SDK.
So clearly whoever saved that project had saved it while the "Target Device" was set to "Windows Mobile 5.0" (and probably created the project in the first place by choosing the WM 5.0 template). Since the WM 5.0 SDK doesn't ship with VS2005, any machine (like my tablet) that hasn't had the WM 5.0 SDK installed fails to open the project.
As I didn't have time at this instance to download the SDK (or switch to my main machine that has the SDK installed), I opened the csproj file in notepad, located the following line:
<PlatformID>4118C335-430C-497f-BE48-11C3316B135E</PlatformID>
... and changed it to this one:
<PlatformID>3C41C503-53EF-4c2a-8DD4-A8217CAD115E</PlatformID>
Save and close, now reopen in Visual Studio and all is fine (with Target Device set to "Pocket PC 2003").
While it makes no difference, I also changed the OSVersion tag, since it points to 5.01, which is not the WinCE version that PPC2003 is based on: 4.20
Finally note that if you *can* open your project and *then* need to change the platform, you don't have to mess with the text files, simply choose Project->Change Target Platform.
Labels: Mobile and Embedded
Friday, April 21, 2006
Get the SP1 Beta for the .NET Compact Framework v2.0
Those that have been waiting for WinCE 4.2 or for headless support need not wait any longer.
However, neither that nor the bug fixes nor the other *new* features excite me more than theTuneIn Remote Performance Monitor. Finally, when people ask me about .NET Compact Framework performance tools I won't have to apologise on behalf of the NETCF team :-D
Those that have been waiting for WinCE 4.2 or for headless support need not wait any longer.
However, neither that nor the bug fixes nor the other *new* features excite me more than the
Labels: Mobile and Embedded
Sunday, January 15, 2006
While today we are on v2 of the .NET Compact Framework (2.0.5238.0), you can of course have v1.0 (there never was a v1.1) side by side on the target.
NETCF v1 had three service packs and the SP3 version number is 1.0.4292.0 (for the full list of version numbers and how to determine what is on your target see this).
So it was a surprise to me when I run cgacutil.exe (in the Windows directory) on my jasjar and it reported the correct v2 version but a new (to me) v1 version: 1.0.4292.2
It turns out (thanks Nazim Lala) that revision 2 is specific to Windows Mobile 5.0 (a loader security fix).
When I created a v1 app and run it on the device the plot thickened: my call to
The answer is both. From an end user/developer point of view, nothing has changed so the hard-coded version returned by the API remains (by design) the same (thanks Jeremy Hance).
(so now you know :-)
NETCF v1 had three service packs and the SP3 version number is 1.0.4292.0 (for the full list of version numbers and how to determine what is on your target see this).
So it was a surprise to me when I run cgacutil.exe (in the Windows directory) on my jasjar and it reported the correct v2 version but a new (to me) v1 version: 1.0.4292.2
It turns out (thanks Nazim Lala) that revision 2 is specific to Windows Mobile 5.0 (a loader security fix).
When I created a v1 app and run it on the device the plot thickened: my call to
System.Environment.Version.ToString() returned 1.0.4292.0 – so which is correct, the API or cgacutil?The answer is both. From an end user/developer point of view, nothing has changed so the hard-coded version returned by the API remains (by design) the same (thanks Jeremy Hance).
(so now you know :-)
Labels: Mobile and Embedded
Saturday, December 10, 2005
Visual Studio 2005 includes some of the remote tools that previously we had to install eVC to get. They are still not integrated in the IDE but you can find them from the Windows Start menu same place where the VS2005 item is. The Windows CE Remote Spy didn't work in pre-release versions but obviously with RTM it does so take it for a spin. One of its features is listing all windows on the target including the handle, caption and class. The typical way you use this info is with FindWindow e.g. as shown here for programmatically closing any open msgbox on your device.
Anyway... If you use Remote Spy with Compact Framework v1 SP3 applications, you'll find that the class name of the CF forms show up as
However, there is another special window that every CF v1 application has (one per app instance) and that has a class of
The moral of the story is, if you do take advantage of undocumented features, your application may break when you move it to the next version regardless of the compatibility efforts of the product teams at MSFT.
Anyway... If you use Remote Spy with Compact Framework v1 SP3 applications, you'll find that the class name of the CF forms show up as
#NETCF_AGL_BASE_. If you go a step further, reference the Microsoft.WindowsCE.Forms assembly and then simply create an instance of the MessageWindow, you will observe how its class is #NETCF_AGL_MSG_. I was told a long time ago not to rely on these facts as they are internal implementation details of the NETCF windowing system. Well, I checked for v2 apps and nothing has changed with those two.However, there is another special window that every CF v1 application has (one per app instance) and that has a class of
#NETCF_AGL_PARK_. Furthermore, its caption is the file system path to your application. This *has changed* with CF v2: now its caption is empty, and the class is #NETCF_AGL_PARK_ appended with the application's file system path.The moral of the story is, if you do take advantage of undocumented features, your application may break when you move it to the next version regardless of the compatibility efforts of the product teams at MSFT.
Labels: Mobile and Embedded
Thursday, December 08, 2005
About 3 months ago I switched to a PocketPC Phone Edition 2003 SE device as my main phone (shocking that it took me so long, but it did). One of the things that really pisses me off is adding new contacts on the device:
1. Create a new contact
2. Populate the contact including entering the Name field: "Name Surname"
3. OK it and go back to the Contacts list
ACTUAL RESULT:
4. You get a an item in the list that reads "Surname, Name"
$%^&££$&*ing thing!
DESIRED RESULT:
4. Get an item that displays as "Name Surname".
I thought Windows Mobile 5.0 would have fixed this (e.g. by offering the FileAs option available on Outlook on the desktop), but when I received my JasJar (thanks Mike!), I found the same pain is there. So I am trying to find how I can change this on the device (forget synching with Outlook). Someone please tell me how and put me out of my misery.
Anyway, if you can't find how to do it on the UI, next step is to do it programmatically I guess, so that is what I did (it is so easy):
1. Create a new Windows Mobile 5.0 project in VS2005. Choose the Smart Device Project/Console project type.
2. Add a project reference to Microsoft.WindowsMobile.PocketOutlook
3. Replace Main with your own:
If you are targeting a WM2003 device, create the appropriate project for that and instead of adding a reference to the Microsoft assembly, add a reference to InTheHand equivalents.
Naturally, you can create a fancy UI to select which ones to change etc but the above is all I wanted. I run it every time I add new contacts.
1. Create a new contact
2. Populate the contact including entering the Name field: "Name Surname"
3. OK it and go back to the Contacts list
ACTUAL RESULT:
4. You get a an item in the list that reads "Surname, Name"
$%^&££$&*ing thing!
DESIRED RESULT:
4. Get an item that displays as "Name Surname".
I thought Windows Mobile 5.0 would have fixed this (e.g. by offering the FileAs option available on Outlook on the desktop), but when I received my JasJar (thanks Mike!), I found the same pain is there. So I am trying to find how I can change this on the device (forget synching with Outlook). Someone please tell me how and put me out of my misery.
Anyway, if you can't find how to do it on the UI, next step is to do it programmatically I guess, so that is what I did (it is so easy):
1. Create a new Windows Mobile 5.0 project in VS2005. Choose the Smart Device Project/Console project type.
2. Add a project reference to Microsoft.WindowsMobile.PocketOutlook
3. Replace Main with your own:
static void Main(string[] args){
OutlookSession os = new OutlookSession();
ContactCollection cc = os.Contacts.Items;
for (int j = 0; j < cc.Count; j++){
Contact c = cc[j];
string s = c.FileAs;
int i = s.IndexOf(',');
if (i > 0){
string s1 = s.Substring(0, i);
string s2 = s.Substring(i + 2, s.Length - i - 2);
c.FileAs = s2 + " " + s1;
c.Update();
}
}
cc.Dispose();
os.Dispose();
}If you are targeting a WM2003 device, create the appropriate project for that and instead of adding a reference to the Microsoft assembly, add a reference to InTheHand equivalents.
Naturally, you can create a fancy UI to select which ones to change etc but the above is all I wanted. I run it every time I add new contacts.
Labels: Mobile and Embedded
Sunday, November 20, 2005
It is always nice to see something you created being used by others. In this case I am referring to my MSDN article.
Udo Killermann sent me a project he wrote that use the P2PMessageQueue component to monitor device plug-n-play events.
You can also use the DeviceStatusMonitor in the SDF from OpenNETCF (guest,guest), which in v2 also uses the P2PMessageQueue, but Udo wanted a stand-alone example.
Download his project here, and any questions regarding the PnP project must be sent to 'udo dot killermann at web dot de' and not me!
Udo Killermann sent me a project he wrote that use the P2PMessageQueue component to monitor device plug-n-play events.
You can also use the DeviceStatusMonitor in the SDF from OpenNETCF (guest,guest), which in v2 also uses the P2PMessageQueue, but Udo wanted a stand-alone example.
Download his project here, and any questions regarding the PnP project must be sent to 'udo dot killermann at web dot de' and not me!
Labels: Mobile and Embedded
Wednesday, November 16, 2005
I meet a lot of experienced .NET developers lately (including colleagues) that have focused on WinForms or ASP.NET or other .NET areas, but have never dabbled with the .NET Compact Framework. It doesn't take long before out conversation ends up in me providing information on how to get started with NETCF development. Here goes for future reference
1. The very first thing to do is to install Visual Studio 2005 (it side by sides with earlier VS versions).
[ The Express editions are no good to you but Standard and above will do perfectly. There is also a stand alone SDK and you could even try Visual Studio.NET 2003 Professional or higher, but my advice is to get Visual Studio 2005. ]
2. (optional) If you are planning on targeting Windows Mobile 5.0 devices, then you also need to download the Windows Mobile 5.0 SDK (i.e. for SmartPhone and PocketPC). In this case, you also need to get ActiveSync v4 (install this *over* your existing ActiveSync v3).
3. Create a new project via the normal route, but choose the “Smart Device” node and then the appropriate self-explanatory project type (e.g. “Device Application”). Note that VS2005 also supports creating apps that target Compact Framework v1.0 (there never was a NETCF v1.1). I recommend you stick with the v2.0 projects.
4. Drag a button on the form and add an event handler to it as you normally would, and type:
5. Start debugging the application: note how you have to choose where to deploy your application (i.e. an emulator type), choose whatever you want (e.g. “Pocket PC 2003 SE Emulator” and then “Deploy”) and notice how your application runs and you can click the button to get your msgbox (this may take a few minutes if this is the first time you are deploying).
6. From the IDE, click the "Stop" to stop debugging your application (emulator remains running, but your application has exited).
7. (optional) There are also some platform considerations, read these
8. (optional) If you need to share/execute your CF code on the desktop, see this.
9. (optional) For some links on how the NETCF differs from the full framework, see here
10. (optional) Remember the netcf is not a strict subset
From here on, you can start developing that NETCF app you’ve always dreamed of :-)
You will run into issues and you will have questions. You are a smart guy/girl so, before you ask me for help, check that your question isn't already answered in the FAQ (old and new), search the netcf newsgroup via google and check that OpenNETCF hasn't addressed the limitation you face. If you still haven't got a resolution, now you can seek support. Luckily there is a vibrant netcf community and for NETCF v2 the MSDN forums rock.
Welcome to the world of mobile development. Isn’t it much more satisfying running your own creation on your pda/phone than on the desktop? The mobility space *will* take off big time in 2006. Good luck!
1. The very first thing to do is to install Visual Studio 2005 (it side by sides with earlier VS versions).
[ The Express editions are no good to you but Standard and above will do perfectly. There is also a stand alone SDK and you could even try Visual Studio.NET 2003 Professional or higher, but my advice is to get Visual Studio 2005. ]
2. (optional) If you are planning on targeting Windows Mobile 5.0 devices, then you also need to download the Windows Mobile 5.0 SDK (i.e. for SmartPhone and PocketPC). In this case, you also need to get ActiveSync v4 (install this *over* your existing ActiveSync v3).
3. Create a new project via the normal route, but choose the “Smart Device” node and then the appropriate self-explanatory project type (e.g. “Device Application”). Note that VS2005 also supports creating apps that target Compact Framework v1.0 (there never was a NETCF v1.1). I recommend you stick with the v2.0 projects.
4. Drag a button on the form and add an event handler to it as you normally would, and type:
MessageBox.Show("It isn't that different, is it?").5. Start debugging the application: note how you have to choose where to deploy your application (i.e. an emulator type), choose whatever you want (e.g. “Pocket PC 2003 SE Emulator” and then “Deploy”) and notice how your application runs and you can click the button to get your msgbox (this may take a few minutes if this is the first time you are deploying).
6. From the IDE, click the "Stop" to stop debugging your application (emulator remains running, but your application has exited).
7. (optional) There are also some platform considerations, read these
8. (optional) If you need to share/execute your CF code on the desktop, see this.
9. (optional) For some links on how the NETCF differs from the full framework, see here
10. (optional) Remember the netcf is not a strict subset
From here on, you can start developing that NETCF app you’ve always dreamed of :-)
You will run into issues and you will have questions. You are a smart guy/girl so, before you ask me for help, check that your question isn't already answered in the FAQ (old and new), search the netcf newsgroup via google and check that OpenNETCF hasn't addressed the limitation you face. If you still haven't got a resolution, now you can seek support. Luckily there is a vibrant netcf community and for NETCF v2 the MSDN forums rock.
Welcome to the world of mobile development. Isn’t it much more satisfying running your own creation on your pda/phone than on the desktop? The mobility space *will* take off big time in 2006. Good luck!
Labels: Mobile and Embedded
Monday, November 14, 2005
As you know, NETCF 2.0 supports WinCE 5.0, PocketPC 2003 and Windows Mobile 5.0 devices.
After much pressure on the fantastic netcf team, they have allowed a few of us to blog this exciting news:
Service Pack 1 of .NET Compact Framework v2.0 will offer support for custom Windows CE 4.2 devices:
• Runtime support only
• Support on all WinCE processor types
I can’t tell you anything else but if you have feedback/requests on this particular topic, log them at the product feedback center (ladybug). The NETCF team is listening!
After much pressure on the fantastic netcf team, they have allowed a few of us to blog this exciting news:
Service Pack 1 of .NET Compact Framework v2.0 will offer support for custom Windows CE 4.2 devices:
• Runtime support only
• Support on all WinCE processor types
I can’t tell you anything else but if you have feedback/requests on this particular topic, log them at the product feedback center (ladybug). The NETCF team is listening!
Labels: Mobile and Embedded
Tuesday, September 20, 2005
.NET Full Framework changes between versions
.NET Compact Framework v1.0 service pack changes/fixes
.NET v1.1 differences with .NETCF v1.0 (also download the class comparison chm)
For netcf 2.0, the document above still mostly applies but keep in mind that CF 2.0 has even more exclusive classes and it now supports COM Interop and multimodule assemblies. See the msdn2 page for an overview of what is new in CF 2.0 and this one for differences with full fx.
Finally, here is what you've all been waiting for: CF 1.0 versus CF 2.0 at an API level.
.NET Compact Framework v1.0 service pack changes/fixes
.NET v1.1 differences with .NETCF v1.0 (also download the class comparison chm)
For netcf 2.0, the document above still mostly applies but keep in mind that CF 2.0 has even more exclusive classes and it now supports COM Interop and multimodule assemblies. See the msdn2 page for an overview of what is new in CF 2.0 and this one for differences with full fx.
Finally, here is what you've all been waiting for: CF 1.0 versus CF 2.0 at an API level.
Labels: Mobile and Embedded
# posted by The Moth @ 1:37:00 PM
Monday, September 19, 2005
This blog entry is for you if:
You have been using Visual Studio 2005 Beta 2 (and all the previous CTPs) but have "ignored" all releases in the last 5 months. Now you download VS2005 Release Candidate and want to know what is new in NETCF 2.0
+ New classes:
SuppressMessageAttribute (as requested)
GeneratedCodeAttribute
SelectionRange
- Removed Classes:
ThreadTerminateException
+ New members:
HardwareKeys.None
Control.InvokeRequired (and for all other Controls)
DataGrid.BackColor
TreeNode.Handle
MonthCalendar.GetDisplayRange
Dns.GetHostEntry (as requested)
ThreadPool.GetMaxThreads & .SetMaxThreads (as requested)
MessageWindow.Text (as requested)
Marshal.AllocHGlobal & .FreeHGlobal & .ReAllocHGlobal
+ New Overloads with timeouts:
AutoResetEvent/ManualResetEvent/Mutex/WaitHandle .WaitOne(int millisecondsTimeout, bool exitContext)
Thread.Join(int millisecondsTimeout)
- Removed the setter from the following properties (so now they are read only):
BalloonChangedEventArgs.Visible
DocumentListEventArgs.Path
ResponseSubmittedEventArgs.Response
HelpEventArgs.MousePos
* You may also notice harmless renamings (e.g. MsgBoxResult.OK rather than Ok), massaging of the Generics stuff, changes in the BindingList/BuidingSource area and some System.XML alterations.
On the VSD side, we find full support for Visual Form Inheritance.
You have been using Visual Studio 2005 Beta 2 (and all the previous CTPs) but have "ignored" all releases in the last 5 months. Now you download VS2005 Release Candidate and want to know what is new in NETCF 2.0
+ New classes:
SuppressMessageAttribute (as requested)
GeneratedCodeAttribute
SelectionRange
- Removed Classes:
ThreadTerminateException
+ New members:
HardwareKeys.None
Control.InvokeRequired (and for all other Controls)
DataGrid.BackColor
TreeNode.Handle
MonthCalendar.GetDisplayRange
Dns.GetHostEntry (as requested)
ThreadPool.GetMaxThreads & .SetMaxThreads (as requested)
MessageWindow.Text (as requested)
Marshal.AllocHGlobal & .FreeHGlobal & .ReAllocHGlobal
+ New Overloads with timeouts:
AutoResetEvent/ManualResetEvent/Mutex/WaitHandle .WaitOne(int millisecondsTimeout, bool exitContext)
Thread.Join(int millisecondsTimeout)
- Removed the setter from the following properties (so now they are read only):
BalloonChangedEventArgs.Visible
DocumentListEventArgs.Path
ResponseSubmittedEventArgs.Response
HelpEventArgs.MousePos
* You may also notice harmless renamings (e.g. MsgBoxResult.OK rather than Ok), massaging of the Generics stuff, changes in the BindingList/BuidingSource area and some System.XML alterations.
On the VSD side, we find full support for Visual Form Inheritance.
Labels: Mobile and Embedded
# posted by The Moth @ 12:57:00 PM
Saturday, August 13, 2005
My MSDN article is now online. Check it out and, as always, let me have your comments.
(Had it been published in exactly 3 weeks time, the employer name under the author name would have been "Avanade", of course...)
Point-to-Point Message Queues with the .NET Compact Framework
(Had it been published in exactly 3 weeks time, the employer name under the author name would have been "Avanade", of course...)
Point-to-Point Message Queues with the .NET Compact Framework
Labels: Mobile and Embedded
# posted by The Moth @ 2:55:00 PM
When you run the code under the full framework, you can see the ArgumentOutOfRangeException: "Index and length must refer to a location within the string. Parameter name: length".
String s1 = "Some string";
this.Text = s1.Substring(1, s1.Length)
When you run it under the .net compact framework v1.0 you see nothing. It is too tolerant (bug).
This is now fixed in netcf v2.0 so if you try the same code you'll get a ArgumentOutOfRangeException: "Specified argument was out of the range of valid values."
If your app took advantage of the bug it will now crash. It is for reasons like this you'd want to run your app in compatibility mode under netcf 2.0 (unless you can recompile your code under CF v2.0, of course).
However, in this case, that won't help you... until we get some msft comments, I guess it is probably a bug in the compatibility mode or maybe compatibility is only there for by-design changes and does not extend to bug fixes...
Labels: Mobile and Embedded
# posted by The Moth @ 8:10:00 AM
Thursday, August 11, 2005
Most PPC apps use the SIP (see point 1 here). Now that resx files are compatible, many developers will try to share code at the windows forms level.
So rather than try to conditionally compile in or out the
So, add a new code file to your project (and share it in both projects) that has the following:
to
If you get any compile errors it means you were assigning
a) Review that design decision
b) If you stick with it, change the
Now in your desktop project, wherever you were going to code the following:
instead code:
So rather than try to conditionally compile in or out the
InputPanel do the following: in your desktop project only, simply add a file that provides stubs for the InputPanel class:namespace Microsoft.WindowsCE.Forms {
public class InputPanel {
public event EventHandler EnabledChanged;
private bool mDummy;
public bool Enabled {
get { return mDummy; }
set { mDummy = value;}
}
}
}Next hurdle will be changing the cursor. On the full framework, every control has a Cursor property and that is what you assign; on the compact framework, there is a single cursor which you access globally through Cursor.CurrentSo, add a new code file to your project (and share it in both projects) that has the following:
namespace YourNamespace {
public static class TheCursor {
public static void CursorCurrent(Control c, Cursor defaultOrWait) {
#if FULL_FRAME
if (c != null) {
c.Cursor = defaultOrWait;
}
#else
Cursor.Current = defaultOrWait;
#endif
}
}
}Now, through a global find and replace (which I usually advocate against), replace all occurrences of:Cursor.Current = Cursors.Default andCursor.Current = Cursors.WaitCursor to
TheCursor.CursorCurrent(this, Cursors.Default) andTheCursor.CursorCurrent(this, Cursors.WaitCursor) respectively.If you get any compile errors it means you were assigning
Cursor.Current from a method of a class that is not a control:a) Review that design decision
b) If you stick with it, change the
this to nullNow in your desktop project, wherever you were going to code the following:
someControlOrFormEtc.Current = Cursors.Default andsomeControlOrFormEtc.Current = Cursors.WaitCursor instead code:
TheCursor.CursorCurrent(someControlOrFormEtc, Cursors.Default) andTheCursor.CursorCurrent(someControlOrFormEtc, Cursors.WaitCursor) respectively.Labels: Mobile and Embedded
# posted by The Moth @ 4:33:00 PM
We say that the .NET Compact Framework is a compatible subset of the full .NET Framework with few elements existing in the netcf and not the full fx.
For v1.0 I've mentioned previously and allow me to quote:
"[...] the CF is a subset of the full framework, but a closer look reveals functionality specific to the CF in the Microsoft.WindowsCE namespace (such as MessageWindow and InputPanel), the infrared classes and of course the SQL stuff is different."
MSDN has a couple more links for those compact framework unique areas here and here.
With v2.0, the CF-exclusive classes grow.
In particular, the Microsoft.WindowsCE.Forms namespace gains the following elements:
1. HardwareButton
2. MobileDevice.Hibernate
3. SystemSettings.ScreenOrientation
4. DocumentList
5. Notification
6. LogFont
NETCF 2.0 also adds the Microsoft.WindowsMobile.DirectX and .Direct3D namespace (as I mentioned here).
That's it... everything else in the compact framework is API compatible with the full framework. Happy reading :-)
For v1.0 I've mentioned previously and allow me to quote:
"[...] the CF is a subset of the full framework, but a closer look reveals functionality specific to the CF in the Microsoft.WindowsCE namespace (such as MessageWindow and InputPanel), the infrared classes and of course the SQL stuff is different."
MSDN has a couple more links for those compact framework unique areas here and here.
With v2.0, the CF-exclusive classes grow.
In particular, the Microsoft.WindowsCE.Forms namespace gains the following elements:
1. HardwareButton
2. MobileDevice.Hibernate
3. SystemSettings.ScreenOrientation
4. DocumentList
5. Notification
6. LogFont
NETCF 2.0 also adds the Microsoft.WindowsMobile.DirectX and .Direct3D namespace (as I mentioned here).
That's it... everything else in the compact framework is API compatible with the full framework. Happy reading :-)
Labels: Mobile and Embedded
# posted by The Moth @ 10:20:00 AM
Monday, August 08, 2005
Everybody knows that to show the Soft Input Panel on a WindowsCE device you have to use the
A common request, to which there is no clean answer, is to show the SIP in numeric mode or not so the user doesn't have to do it.
However, Alex Feinman has a great hack that provides just that; it checks for the color of the "123" button and sends a windows message depending on if it is black or white (pressed or not). Go download it here.
If you are targeting PocketPCs then use it and that is the end of the story, see you next time.
If you are targeting custom Windows CE devices, you need to make a few small changes (on our platform we are using the small keyboard with the "Large Keys"):
1. The calls to
2. Change the last parameter in the two calls to
3. Change the condition so it caters for showing a numeric sip in non-numeric mode.
I've wrapped the changes in an InputPanelEx class:
a) In your projects replace all occurrences of
b) Wherever you have
Microsoft.WindowsCE.InputPanel (set the Enabled property to true/false to show/hide).A common request, to which there is no clean answer, is to show the SIP in numeric mode or not so the user doesn't have to do it.
However, Alex Feinman has a great hack that provides just that; it checks for the color of the "123" button and sends a windows message depending on if it is black or white (pressed or not). Go download it here.
If you are targeting PocketPCs then use it and that is the end of the story, see you next time.
If you are targeting custom Windows CE devices, you need to make a few small changes (on our platform we are using the small keyboard with the "Large Keys"):
1. The calls to
GetPixel/SetPixel take the X,Y coordinates which are hard coded to 2,2. Change the Y to be 77.2. Change the last parameter in the two calls to
Message.Create to be: new IntPtr(0x00490009).3. Change the condition so it caters for showing a numeric sip in non-numeric mode.
I've wrapped the changes in an InputPanelEx class:
a) In your projects replace all occurrences of
InputPanel to InputPanelEx.b) Wherever you have
inputPanel1.Enabled = true, add another line inputPanel1.Show(true) [if you want to show numeric SIP].Labels: Mobile and Embedded
# posted by The Moth @ 12:25:00 PM
Monday, August 01, 2005
The punchline is that with VS2005 there is no more incompatibility for resource files (resx) between the compact and full frameworks!
To quote from my post on writing cross-platform code with VS.NET 2003:
"Trying to share the form code would effectively mean not using the designer at all."
This statement is no longer true with VS2005. You can follow the steps for sharing code files (as described in that blog entry) for forms as well. You may still prefer not to share forms between the two platforms but at least it will be technically possible now.
A side effect is that we no longer need cfresgen (as previously mentioned here) and instead we can use resgen (for both platforms).
Another side effect of this improvement is that existing resx files you have that work in your cf v1.0 projects, cannot be added to VS2005 projects. They have to go through the upgrade wizard. So although you have been told that the VS2005 upgrade wizard only affects solution and project files and nothing else, now you know that it also affects resx files; even though the (Beta 2) conversion report does not indicate that!
Overall, good stuff from the VSD team (and in this particular case, Xin Yan).
To quote from my post on writing cross-platform code with VS.NET 2003:
"Trying to share the form code would effectively mean not using the designer at all."
This statement is no longer true with VS2005. You can follow the steps for sharing code files (as described in that blog entry) for forms as well. You may still prefer not to share forms between the two platforms but at least it will be technically possible now.
A side effect is that we no longer need cfresgen (as previously mentioned here) and instead we can use resgen (for both platforms).
Another side effect of this improvement is that existing resx files you have that work in your cf v1.0 projects, cannot be added to VS2005 projects. They have to go through the upgrade wizard. So although you have been told that the VS2005 upgrade wizard only affects solution and project files and nothing else, now you know that it also affects resx files; even though the (Beta 2) conversion report does not indicate that!
Overall, good stuff from the VSD team (and in this particular case, Xin Yan).
Labels: Mobile and Embedded
# posted by The Moth @ 4:05:00 PM
Thursday, July 28, 2005
One of the features that devs got excited with when Visual Studio .NET 2002 launched, is Visual Form Inheritance. I have never used this feature in a commercial app but I guess I can see its appeal.
.NET Compact Framework v1.0 projects do not support Visual Form Inheritance in the designer (you cannot view the results of inheriting your form from another of your own forms). Specifically, if you attempt to directly inherit from anything other than System.Windows.Form, the winforms designer will not render your form's design surface. However, your application will still compile and execute with the visual inheritance correctly observed at run time.
With Visual Studio .NET 2003, you should do your design work before changing the parent of your form to be another form (i.e. do it while it still inherits from Form and the designer works). When you need the designer again, change your class to inherit from System.Windows.Forms.Form
This has been discussed multiple time previously in the newsgroup archives e.g. here
So what is the story with v2.0 of the compact framework and Visual Studio 2005?
Start with a new Device Application with a single form and add some controls to it. If you navigate to "Project->Add New Item", the dialog does not include the "Inherited Form" template (in Beta 2). However, you can add a "Windows Form" and then change the code to achieve visual form inheritance. Here are the steps:
1. Create a new Smart Device Project
2. To the default Form1, add a button
3. Add a new form (Form2)
4. Delete the mainmenu from Form2
5. Go to the code and change it (Form2.cs) so it does not inherit from Form and instead inherits from Form1
6. Rebuild the solution
7. Open Form2 in the designer and observe how it shows button1
If you are using VB, make sure at step 5 you go to the Form2.Designer.vb (instead of the Form2.vb) - see my previous post on partial classes and how to get to the designer file.
Hopefully by RTM the VSD team will add the template so it will be even easier!
UPDATE: September 2005 - Visual Studio 2005 Release Candidate supports the "Inherited Form" template
.NET Compact Framework v1.0 projects do not support Visual Form Inheritance in the designer (you cannot view the results of inheriting your form from another of your own forms). Specifically, if you attempt to directly inherit from anything other than System.Windows.Form, the winforms designer will not render your form's design surface. However, your application will still compile and execute with the visual inheritance correctly observed at run time.
With Visual Studio .NET 2003, you should do your design work before changing the parent of your form to be another form (i.e. do it while it still inherits from Form and the designer works). When you need the designer again, change your class to inherit from System.Windows.Forms.Form
public class Form4
//: System.Windows.Forms.Form // Use this line for design time
: Form2 // Use this line for runtime
This has been discussed multiple time previously in the newsgroup archives e.g. here
So what is the story with v2.0 of the compact framework and Visual Studio 2005?
Start with a new Device Application with a single form and add some controls to it. If you navigate to "Project->Add New Item", the dialog does not include the "Inherited Form" template (in Beta 2). However, you can add a "Windows Form" and then change the code to achieve visual form inheritance. Here are the steps:
1. Create a new Smart Device Project
2. To the default Form1, add a button
3. Add a new form (Form2)
4. Delete the mainmenu from Form2
5. Go to the code and change it (Form2.cs) so it does not inherit from Form and instead inherits from Form1
6. Rebuild the solution
7. Open Form2 in the designer and observe how it shows button1
If you are using VB, make sure at step 5 you go to the Form2.Designer.vb (instead of the Form2.vb) - see my previous post on partial classes and how to get to the designer file.
Hopefully by RTM the VSD team will add the template so it will be even easier!
UPDATE: September 2005 - Visual Studio 2005 Release Candidate supports the "Inherited Form" template
Labels: Mobile and Embedded
# posted by The Moth @ 12:54:00 PM
Thursday, July 21, 2005
In my previous post I linked to a class diagram that shows all the WM 5.0 managed namespaces. It turns out that diagram doesn't show the WindowsMobile.Forms namespace so here it is for your enjoyment:
Had I drawn it in a C# project all those 'As' would be ':' conforming to UML style but I'll refrain from going on about that again.
Had I drawn it in a C# project all those 'As' would be ':' conforming to UML style but I'll refrain from going on about that again.
Labels: Mobile and Embedded
# posted by The Moth @ 12:08:00 PM
Wednesday, July 20, 2005
All of you know that Windows Mobile 5.0 was released in May at MEDC (Bill Gates keynote). Devices are expected to ship in Q4 this year.
From a general dotnet perspective, the most exciting thing about this platform release is that it exposes managed APIs! This is a first in both the mobile/embedded and desktop/server world. Maybe Longhorn will be the next, but for now WM 5.0 is the first and only one to do that.
What prompted me to share this is that already there are articles etc that refer to these APIs as being part of .NET Compact Framework v2.0 - they are not, they are part of the platfrom (which also includes CF 1.0 SP3 by the way). If you use netcf 2.0 to target a WM2003 or a WinCE 5.0 device, the APIs are not available. In contrast, if you use netcf v1.0 to target a WM 5.0 device then the APIs are available.
There is a lot of redundancy in my statements above but hopefully it will clarify the state of play (my fear is that this will become another common misconception similar to people talking about v1.1 of compact framework - when there is only v1.0 and v2.0).
The APIs I refer to are classes in the following namespaces:
Microsoft.WindowsMobile.PocketOutlook
Microsoft.WindowsMobile.Configuration
Microsoft.WindowsMobile.Status
Microsoft.WindowsMobile.Telephony
Microsoft.WindowsMobile.Forms
You can access them from Visual Studio 2005 once you download the WM 5.0 SDK and after you add reference to the relevant assemblies (same as namespace names with "dll" suffix)
Just to confuse things, there is a netcf 2.0 namespace with similar name: Microsoft.WindowsMobile.DirectX. If you are into game programming, check it out and also the article here
So, before I let you go back to your work, here is a link if you wish to find out more: recorded webcast & class diagram (the one missing is the Forms namespace which you can see here)
Oh, I almost forgot, if you like the new classes and would like to see them on earlier PPC versions (e.g. PPC 2003), check this out :-)
From a general dotnet perspective, the most exciting thing about this platform release is that it exposes managed APIs! This is a first in both the mobile/embedded and desktop/server world. Maybe Longhorn will be the next, but for now WM 5.0 is the first and only one to do that.
What prompted me to share this is that already there are articles etc that refer to these APIs as being part of .NET Compact Framework v2.0 - they are not, they are part of the platfrom (which also includes CF 1.0 SP3 by the way). If you use netcf 2.0 to target a WM2003 or a WinCE 5.0 device, the APIs are not available. In contrast, if you use netcf v1.0 to target a WM 5.0 device then the APIs are available.
There is a lot of redundancy in my statements above but hopefully it will clarify the state of play (my fear is that this will become another common misconception similar to people talking about v1.1 of compact framework - when there is only v1.0 and v2.0).
The APIs I refer to are classes in the following namespaces:
Microsoft.WindowsMobile.PocketOutlook
Microsoft.WindowsMobile.Configuration
Microsoft.WindowsMobile.Status
Microsoft.WindowsMobile.Telephony
Microsoft.WindowsMobile.Forms
You can access them from Visual Studio 2005 once you download the WM 5.0 SDK and after you add reference to the relevant assemblies (same as namespace names with "dll" suffix)
Just to confuse things, there is a netcf 2.0 namespace with similar name: Microsoft.WindowsMobile.DirectX. If you are into game programming, check it out and also the article here
So, before I let you go back to your work, here is a link if you wish to find out more: recorded webcast & class diagram (the one missing is the Forms namespace which you can see here)
Oh, I almost forgot, if you like the new classes and would like to see them on earlier PPC versions (e.g. PPC 2003), check this out :-)
Labels: Mobile and Embedded
# posted by The Moth @ 3:20:00 PM
Thursday, June 02, 2005
As a Pocket PC user and a NETCF 1.0 developer, you are familiar with the problem of showing different forms in the same application while preventing the user from navigating between forms from the "running list" (not to mention returning to the correct form after closing a sub-form). This was described previously here (look at the fourth entry: 4. Moving between applications)
So in NETCF 1.0, if you simply use
a) The new form (specifically its caption/text) appears in the "running programs list"
b) The original form also appears in the list, which means you can navigate to it (although it appears disabled once activated)
c) There is potential for closing the second form and returning to another window on the PPC (the original form has moved back in the z-order)
With CF 2.0 you can use the new Owner property of the Form and hence get rid of every problem from the above list. Do not confuse the Owner property with the
Run the following snippet (assume it is in the button click event handler of Form1 in VS2005 NETCF 2.0 project):
So in NETCF 1.0, if you simply use
ShowDialog to display another form:a) The new form (specifically its caption/text) appears in the "running programs list"
b) The original form also appears in the list, which means you can navigate to it (although it appears disabled once activated)
c) There is potential for closing the second form and returning to another window on the PPC (the original form has moved back in the z-order)
With CF 2.0 you can use the new Owner property of the Form and hence get rid of every problem from the above list. Do not confuse the Owner property with the
Parent property, which is inherited from Control and is not intended to be used with formsRun the following snippet (assume it is in the button click event handler of Form1 in VS2005 NETCF 2.0 project):
Dim f As New Form2()...you'll notice that only one entry for your application exists in the running list. The only potentially strange thing is that it has the caption of the first form (while the body of the form is clearly that of Form2)! This is easily rectified with the following modification (this time in C#):
f.Owner = Me
f.ShowDialog()
Form2 f = new Form2();Although I would have preferred the original snippet to exhibit the behaviour of the second snippet, still we must agree that this is a step forward from NETCF 1.0!
f.Owner = this;
string s = this.Text; //make a copy of the original caption
this.Text = f.Text; //set our caption to the form we are about to show
f.ShowDialog();
this.Text = s; //restore the original caption once the second form is closed
Labels: Mobile and Embedded
# posted by The Moth @ 12:52:00 PM
Friday, May 20, 2005
Now that NETCF 2.0 supports COM Interop (for CF 1.0 your best bet is 3rd party support), there is a FAQ emerging.
Q: I have a native/C++ exe/process and cannot get it to talk to my managed/C#/VB dll/class library. What's wrong?
A: As indicated last year, this is not supported.
To help Google get you here, I will use various phraseologies that all indicate the same thing.
You can call native COM components from managed code, as long as it is from a managed exe - VS will generate the RCW (Remote Callable Wraper) for you. Once you have activated native COM objects from managed code, they can call you back; so in that sense - and that sense only - CCW (COM Callable Wrappers) are supported.
You cannot activate (or register) managed objects through COM. Regasm.exe that the full framework supports is not available. Forget doing a CoCreate on your managed objects.
If you think about the last statement it makes sense, since runtime hosting of the NETCF CLR is not supported; how could you start a native process that "talked" to a managed library (dll)?
Incidentally, if you must communicate from native code to managed code and since you cannot do that in the same process, consider one of the IPC mechanisms available on WinCE.
While we are on the subject of NETCF 2.0 COM Interop limitations, allow me to quote from one of Richard Greenberg's slides from MEDC:
"Only MTAs (multi-threaded apartments) are supported and there are no custom marshalers or auto-generated Class Interfaces."
Q: I have a native/C++ exe/process and cannot get it to talk to my managed/C#/VB dll/class library. What's wrong?
A: As indicated last year, this is not supported.
To help Google get you here, I will use various phraseologies that all indicate the same thing.
You can call native COM components from managed code, as long as it is from a managed exe - VS will generate the RCW (Remote Callable Wraper) for you. Once you have activated native COM objects from managed code, they can call you back; so in that sense - and that sense only - CCW (COM Callable Wrappers) are supported.
You cannot activate (or register) managed objects through COM. Regasm.exe that the full framework supports is not available. Forget doing a CoCreate on your managed objects.
If you think about the last statement it makes sense, since runtime hosting of the NETCF CLR is not supported; how could you start a native process that "talked" to a managed library (dll)?
Incidentally, if you must communicate from native code to managed code and since you cannot do that in the same process, consider one of the IPC mechanisms available on WinCE.
While we are on the subject of NETCF 2.0 COM Interop limitations, allow me to quote from one of Richard Greenberg's slides from MEDC:
"Only MTAs (multi-threaded apartments) are supported and there are no custom marshalers or auto-generated Class Interfaces."
Labels: Mobile and Embedded
# posted by The Moth @ 2:15:00 PM
Monday, May 16, 2005
Question:
Do Smart Device Projects (i.e. Compact Framework projects) support unit testing as offered by Visual Studio 2005?
Investigation:
1. In a CF project write the following method:
3. Set the newly created project as startup project (via context menu)
4. Go to the test method and change the following line:
to
5. Comment out the Assert.Inconclusive line
6. Run the project
7. Observe: The PPC emulator starts, which is promising, but unfortunately the unit test passes :-(
It would not pass if it was running against the CF, as the build number is 5056 (the full framework build number for Beta 2 is 50215).
Conclusion:
Unit testing is not supported by CF projects and instead the tests get retargeted to the full framework (much like Deploy to My Computer).
Link:
For an open source project that supports unit tests running on the device, see CFNUnitBridge from Trey
Do Smart Device Projects (i.e. Compact Framework projects) support unit testing as offered by Visual Studio 2005?
Investigation:
1. In a CF project write the following method:
public Int32 GetBuildVersionPart(){
return System.Environment.Version.Build;
}2. Right click on the method and choose "Create Tests...", choose C# and OK, choose default name and OK3. Set the newly created project as startup project (via context menu)
4. Go to the test method and change the following line:
int expected = 0;to
int expected = 50215;5. Comment out the Assert.Inconclusive line
6. Run the project
7. Observe: The PPC emulator starts, which is promising, but unfortunately the unit test passes :-(
It would not pass if it was running against the CF, as the build number is 5056 (the full framework build number for Beta 2 is 50215).
Conclusion:
Unit testing is not supported by CF projects and instead the tests get retargeted to the full framework (much like Deploy to My Computer).
Link:
For an open source project that supports unit tests running on the device, see CFNUnitBridge from Trey
Labels: Mobile and Embedded
# posted by The Moth @ 12:49:00 PM
Friday, May 06, 2005
All Compact Framework developers know that without pinvoking you cannot author any serious CF 1.0 application.
We've all been in the situation where we have declared a function from coredll.dll (or some other native dll) and when we called it we got the infamous MissingMethodException (meaning the DllImport declaration was wrong). That is the only way to find out, try it and see.
Well, CF 2.0 gets support for a method that is already in there in the full desktop .net framework version 1.1. The method in question is Marshal.PreLink/PreLinkAll. It basically verifies that your dllimports have been declared properly, e.g.
My suggestion is to still test the methods explicitly from your code, but I will be using this shortcut when in debug mode; it's a sweet little time saver :-)
We've all been in the situation where we have declared a function from coredll.dll (or some other native dll) and when we called it we got the infamous MissingMethodException (meaning the DllImport declaration was wrong). That is the only way to find out, try it and see.
Well, CF 2.0 gets support for a method that is already in there in the full desktop .net framework version 1.1. The method in question is Marshal.PreLink/PreLinkAll. It basically verifies that your dllimports have been declared properly, e.g.
static void Main() {
// Assuming all your dllimports are in Form1
System.Runtime.InteropServices.Marshal.PrelinkAll(typeof(Form1));
Application.Run(new Form1());
}My suggestion is to still test the methods explicitly from your code, but I will be using this shortcut when in debug mode; it's a sweet little time saver :-)
Labels: Mobile and Embedded
# posted by The Moth @ 12:19:00 AM
Thursday, May 05, 2005
As you may have noticed, in VS2005 you can turn static code analysis on via the project properties ("Enable Code Analysis"). Many of the rules are just guidelines and do not qualify as warnings. There should be a separate category, maybe called *recommendations*. However, that is not the point of this blog post.
Fortunately, you can suppress warnings simply by right clicking on them and choosing "Suppress". What that does is to add an attribute to the line of code that breaks the recommendation so next time you compile/build, the annoying warning will not appear in the error list. The attribute is the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute (it applies only if the compilation constant CODE_ANALYSIS is defined)
Example:
So, you bring up the contextmenu for the item in the "Error List", select "Suppress message" and life is good again.
So where is the problem? As the title of this entry suggests, the attribute is not supported by the Compact Framework (at least in Beta 2) and doesn't compile:
There are two issues with that:
1. You cannot suppress those annoyingrecommendations warnings that shouldn't be there in the first place.
2. If you are sharing code between the full and compact frameworks, you'll get compilation errors.
There is nothing you can do about the 1st one (apart from vote for it).
For the second, as you know, you can use conditional compilation. However, in this case I'd go ahead and define the attribute in code in your CF projects, so at least you get past the compilation problem. Define it like this:
Note, I tried implementing the attribute fully but the warnings were still not suppressed so the bare minimum skeleton as above is good enough to at least get us past the compilation errors
Fortunately, you can suppress warnings simply by right clicking on them and choosing "Suppress". What that does is to add an attribute to the line of code that breaks the recommendation so next time you compile/build, the annoying warning will not appear in the error list. The attribute is the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute (it applies only if the compilation constant CODE_ANALYSIS is defined)
Example:
// no comments on the content of the method pleaseOne of the 4 warnings you'll see for the method above is the following:
public void SomeMethod(bool b, object o) {
if (b) {
((EventHandler)o).Invoke(null, EventArgs.Empty);
} else {
((EventHandler)o).BeginInvoke(null, EventArgs.Empty, null, null);
}
}
CA1800 : Microsoft.Performance : 'o', a parameter, is cast to type 'System.EventHandler' multiple times in method Class1.SomeMethod(Boolean, Object):Void. Cache the result of the 'as' operator or direct cast in order to eliminate the redundant castclass instruction.
So, you bring up the contextmenu for the item in the "Error List", select "Suppress message" and life is good again.
So where is the problem? As the title of this entry suggests, the attribute is not supported by the Compact Framework (at least in Beta 2) and doesn't compile:
The type or namespace name 'CodeAnalysis' does not exist in the namespace 'System.Diagnostics' (are you missing an assembly reference?)
There are two issues with that:
1. You cannot suppress those annoying
2. If you are sharing code between the full and compact frameworks, you'll get compilation errors.
There is nothing you can do about the 1st one (apart from vote for it).
For the second, as you know, you can use conditional compilation. However, in this case I'd go ahead and define the attribute in code in your CF projects, so at least you get past the compilation problem. Define it like this:
namespace System.Diagnostics.CodeAnalysis {
public class SuppressMessageAttribute : Attribute {
public SuppressMessageAttribute(string category, string checkId) {}
}
}Note, I tried implementing the attribute fully but the warnings were still not suppressed so the bare minimum skeleton as above is good enough to at least get us past the compilation errors
Labels: Mobile and Embedded
# posted by The Moth @ 1:52:00 PM
Wednesday, April 27, 2005
While moving some of my cross-platform code from .NET 1.1/CF 1.0 (Visual Studio .NET 2003) over to .NET 2.0/CF 2.0 (Visual Studio 2005) Beta 2…
… the desktop compiler warned me that the following method was obsolete:
No problem, as the helpful warning informed me of the replacement method, so I change my code and it compiled:
I then open my Smart Device project and I encounter an error that GetHostEntry is not recognised (the method is not supported by the CF version of Dns)! I look the class up and it supports Resolve without any obsoletion warning in sight!
The temporary solution is conditional compilation, but I am confident that by RTM the CF team will resolve (no pun intended) this :-)
… the desktop compiler warned me that the following method was obsolete:
System.Net.Dns.Resolve(hostname)No problem, as the helpful warning informed me of the replacement method, so I change my code and it compiled:
System.Net.Dns.GetHostEntry(hostname)I then open my Smart Device project and I encounter an error that GetHostEntry is not recognised (the method is not supported by the CF version of Dns)! I look the class up and it supports Resolve without any obsoletion warning in sight!
The temporary solution is conditional compilation, but I am confident that by RTM the CF team will resolve (no pun intended) this :-)
Labels: Mobile and Embedded
# posted by The Moth @ 2:59:00 PM
Tuesday, April 26, 2005
We looked last time at the VS.NET 2003 support for Smart Device Projects from an intellisense perspective.
VS2005 seems to be miles ahead in that department (as well). In fact, I have yet to find a PME (property, method, event) that compiles while it is not supported _or_ a PME that is supported at runtime and not offered in the IDE :-)
The story is even more interesting. Let's take a control, e.g. TreeView. If you try to add an event handler in code, intellisense lists only the events that are applicable. Now, since TreeView inherits from Control, I know I should be able to add an event handler to an event that is exposed by Control such as DoubleClick or Paint. So, even though intellisense doesn't help me, I can type:
Here is the new feature. This does not result in a compilation error but rather a warning in the "error list" window:
"Members not supported by the Device platform should not be called: System.Windows.Forms.TreeView.add_DoubleClick is not a supported method in this platform".
I like this! If I have explicitly written code that intellisense doesn't recognise I must have my reasons, so don't error out on me - just warn me. E.g. if code is shared between desktop and CE devices, you may avoid the conditional compilation and just not offer the functionality on the CE device. (this does make me think of a feature request to turn every compilation error into a warning, but I'll resist going down that thinking path...)
Needless to say that if you try something like adding an event handler to TreeView.NodeMouseClick event, which is supported in .NET 2.0 but not NETCF 2.0, you do get a compilation error; the warning in the previous case is only because the event is inherited from Control.
VS2005 seems to be miles ahead in that department (as well). In fact, I have yet to find a PME (property, method, event) that compiles while it is not supported _or_ a PME that is supported at runtime and not offered in the IDE :-)
The story is even more interesting. Let's take a control, e.g. TreeView. If you try to add an event handler in code, intellisense lists only the events that are applicable. Now, since TreeView inherits from Control, I know I should be able to add an event handler to an event that is exposed by Control such as DoubleClick or Paint. So, even though intellisense doesn't help me, I can type:
treeView1.DoubleClick += new EventHandler(treeView1_DoubleClick);Here is the new feature. This does not result in a compilation error but rather a warning in the "error list" window:
"Members not supported by the Device platform should not be called: System.Windows.Forms.TreeView.add_DoubleClick is not a supported method in this platform".
I like this! If I have explicitly written code that intellisense doesn't recognise I must have my reasons, so don't error out on me - just warn me. E.g. if code is shared between desktop and CE devices, you may avoid the conditional compilation and just not offer the functionality on the CE device. (this does make me think of a feature request to turn every compilation error into a warning, but I'll resist going down that thinking path...)
Needless to say that if you try something like adding an event handler to TreeView.NodeMouseClick event, which is supported in .NET 2.0 but not NETCF 2.0, you do get a compilation error; the warning in the previous case is only because the event is inherited from Control.
Labels: Mobile and Embedded
# posted by The Moth @ 12:52:00 PM
Monday, April 25, 2005
When writing Compact Framework code with VS.NET 2003, intellisense is smart enough to filter out the framework methods that do not apply to the CF. Truth be told it could be better. There are some properties shown that are not supported by the CF, yet they compile, and hence you only find out at runtime. Some of them will result in runtime exceptions (e.g. changing the Font of a UpDown control) and others will silently do nothing and have no effect (e.g. changing the Size of a StatusBar). I am not sure which outcome is worse, but I do know the methods should not have been available in the IDE in the first place, since a Smart Device Project was chosen! The help is pretty good (but certainly not perfect) at pointing out which class members are applicable to CF.
The area where the IDE is really bad is events. C# shows in the properties window the events that are applicable, but some events are shown even though they are not supported (e.g. PictureBox.Validating) and others are supported and not shown (e.g. PictureBox.Click). In the latter case the workaround is to manually add the events in code (in code there is no filtering so, whether applicable or not, the compiler lets you add event handlers). VB is much worse. As you know, the event handlers are generated by selecting the event names form the top right combobox in the code view; well that combo doesn't even make an attempt at filtering! In case you think the documentation will come to your rescue, think again: the documentation makes no statement about the applicability of events to the CF or not.
To complicate things further, there have been 3 service packs for CF 1.0 and all of them apply to the runtime *not* the VS IDE. Since the SPs, some properties (e.g. BackColor) are available. None of these are shown in the properties window but you have to manually use them through code.
At this point you might be expecting me to offer some solution. Sorry, but there is only one way to face this issue: try out your code before you make assumptions about what is supported or not.
VS2005 is a whole different (more pleasant) story and we'll look at that next time.
The area where the IDE is really bad is events. C# shows in the properties window the events that are applicable, but some events are shown even though they are not supported (e.g. PictureBox.Validating) and others are supported and not shown (e.g. PictureBox.Click). In the latter case the workaround is to manually add the events in code (in code there is no filtering so, whether applicable or not, the compiler lets you add event handlers). VB is much worse. As you know, the event handlers are generated by selecting the event names form the top right combobox in the code view; well that combo doesn't even make an attempt at filtering! In case you think the documentation will come to your rescue, think again: the documentation makes no statement about the applicability of events to the CF or not.
To complicate things further, there have been 3 service packs for CF 1.0 and all of them apply to the runtime *not* the VS IDE. Since the SPs, some properties (e.g. BackColor) are available. None of these are shown in the properties window but you have to manually use them through code.
At this point you might be expecting me to offer some solution. Sorry, but there is only one way to face this issue: try out your code before you make assumptions about what is supported or not.
VS2005 is a whole different (more pleasant) story and we'll look at that next time.
Labels: Mobile and Embedded
# posted by The Moth @ 3:13:00 PM
Monday, April 11, 2005
Recently I needed to change scrollbar colors, the disabled text color and other similar items. The target is a Windows CE device (not a PPC) and I quickly found (through the control panel) the Display Properties dialog and specifically the "Appearance" tab. If you don't have a WinCE device, launch the 4.1 emulator that ships with VS.NET 2003 to check it out.
So there was my goal: to find out what it does under the covers in order to offer us changing colors of individual items (e.g. Active Title Bar color) and also the overall scheme (e.g. Brick). We start at the obvious place: *everything* on this platform is stored in the registry. Using the Remote Registry editor (that comes with eVC) we take a snapshot before and after a scheme change and then use windiff (or similar) to spot the difference. Bingo; we find a string value "Current" under HKCU that stores the scheme name and, more importantly, we find a byte array value "SysColor" under HKLM that stores the color data. Searching on MSDN proves fruitful and informative, leading us to this and this. We test out our understanding by changing some of the RGB values in the registry, flush, reset the unit and the changes take effect. Nice!
Next step is to figure out how the control panel applet applies the change on the fly. We suspect some windows message and decide to investigate further with another eVC tool, remote spy++. Every time we apply a change a WM_SYSCOLORCHANGE message is broadcast. So we try with our own app to change the registry and then broadcast the same message but no effect takes place. Wouldn't it be great if we had the source code to the OS dialog so we could see exactly what it does? But wait, I have platform builder installed on this machine, so I could locate the code and check it out! After a few hit and miss searches, I nail it down. They call an API that does both the writing to the registry and the broadcast and the on-the-fly change: SetSysColors
Note that, if you don't care about changing colors and all you need is read-only access, then the existing System.Drawing.SystemColors class fits the bill.
This has been a not so short story, leading up to providing you with a managed class that wraps all of the above. Use it in your own WinCE (not-PPC) projects for changing color themes on the fly or single element color changes.
Download the VB class here.
Get the C# version as part of the SDF (guest, guest).
So there was my goal: to find out what it does under the covers in order to offer us changing colors of individual items (e.g. Active Title Bar color) and also the overall scheme (e.g. Brick). We start at the obvious place: *everything* on this platform is stored in the registry. Using the Remote Registry editor (that comes with eVC) we take a snapshot before and after a scheme change and then use windiff (or similar) to spot the difference. Bingo; we find a string value "Current" under HKCU that stores the scheme name and, more importantly, we find a byte array value "SysColor" under HKLM that stores the color data. Searching on MSDN proves fruitful and informative, leading us to this and this. We test out our understanding by changing some of the RGB values in the registry, flush, reset the unit and the changes take effect. Nice!
Next step is to figure out how the control panel applet applies the change on the fly. We suspect some windows message and decide to investigate further with another eVC tool, remote spy++. Every time we apply a change a WM_SYSCOLORCHANGE message is broadcast. So we try with our own app to change the registry and then broadcast the same message but no effect takes place. Wouldn't it be great if we had the source code to the OS dialog so we could see exactly what it does? But wait, I have platform builder installed on this machine, so I could locate the code and check it out! After a few hit and miss searches, I nail it down. They call an API that does both the writing to the registry and the broadcast and the on-the-fly change: SetSysColors
Note that, if you don't care about changing colors and all you need is read-only access, then the existing System.Drawing.SystemColors class fits the bill.
This has been a not so short story, leading up to providing you with a managed class that wraps all of the above. Use it in your own WinCE (not-PPC) projects for changing color themes on the fly or single element color changes.
Download the VB class here.
Get the C# version as part of the SDF (guest, guest).
Labels: Mobile and Embedded
# posted by The Moth @ 2:56:00 PM
Wednesday, March 30, 2005
One of the missing methods from NETCF 1.0 today is Thread.IsBackground.
CF 2.0 will support this method with a few noteworthy caveats. Read carefully Brian Smith's contributions in this thread.
CF 2.0 will support this method with a few noteworthy caveats. Read carefully Brian Smith's contributions in this thread.
Labels: Mobile and Embedded
# posted by The Moth @ 1:46:00 PM
Saturday, March 26, 2005
So you have experience developing .NET Compact Framework applications targeting your Pocket PC (2000/2002 or WM2003) or even custom Windows CE devices. Now you want to dabble with SmartPhone 2003 development, since CF supports that too (but not SP2002). Where do you start?
The first thing to do is install the SmartPhone SDK. This will give you a new Smart Device Project type and an emulator of course (you may also get the Second Edition Emulator. Usually you choose the Pocket PC platform, now you should choose Smartphone (the only omission from the "project type" list is the "Non-graphical Application", a.k.a. "Console Application" on the Windows CE platform).
So the new project is created. The first thing you note is that the form is small (182w x 239h). In reality, the area you can manipulate is 176x180 pixels since you'll have a border, title bar and menu area. The menu area is actually the space for two soft keys (more on those in a moment). The second limitation we observe is the toolbox; device controls are already much fewer than the desktop, but they are further halved in numbers for Smartphone projects [VS2003 toolbox][VS2005 toolbox]. Later, I'll say a couple of words for some of the 14 controls (datagrid doesn't work) we have at our disposal.
At this point, it is worth stating the obvious: the SP has no touch screen and all interaction is via hardware buttons. The emulator [vs2003][whidbey] gives us some clues. Let's have a closer look at the buttons moving from the top downwards:
There are 3 sections:
1. LCD area
-Two button directly below the screen (a.k.a. soft keys).
2. Middle/center of the phone
-Two phone keys. Green for call and red for hungup.
-Below the call button there is a "home" button.
-Below the hungup button is a "Back" button.
-Between the 4 buttons just described is the rocker [Left, Right, Top, Down and Enter/Action]
3. Lower end of the phone
-Typical 12-button keypad found on all phones
In theory you could hook into any of these buttons and do whatever you want, but it makes sense to remember that the device's primary use is as a phone and also that MSFT has some guidelines for SP applications (some of which are enforced by the CF at runtime). For example the 12-button keypad can be used only for data entry (e.g. on a textbox); the call/hungup buttons (with the green & red phone icons) should be left alone, as should the home button (house icon). The back button navigates to the previous form (or to the previous application, if you are on the main form).
So let's look at the remainder buttons in correlation to the CF controls.
+ The following controls have no user interaction (other than displaying info, of course):
Label, Panel, PictureBox, ProgressBar, Timer, ImageList, VScrollBar, HScrollBar
+ The following 3 controls should be the only control on a single line (other than non-interactive controls mentioned above, of course):
- CheckBox
Up/Down move to the previous/next control on the form. Left/Right/Enter toggle the state.
- ComboBox
Up/Down move to the previous/next control on the form. Left/Right navigate through items in the combobox list. Enter brings up a full screen list of the items for selecting by scrolling with Up/Down.
- TextBox
Up/Down move to the previous/next control on the form. Left/Right moves the caret in the textbox. The Back button erases a character. If the textbox is Multiline=true, Enter brings up a full screen textbox (with scrollbars, if needed):
+ The following two controls must be the only (interactive) control on the form (there is no automatic way for them to pass focus to another control):
- ListView
Up/Down moves through the listview items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter generates the ItemActivate event.
- TreeView (must be the *only* control on the form)
Up/Down moves through the visible treenode items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter expands/collapses a treenode.
+ Given the absence of buttons, the two soft keys are the main mechanism of performing actions. The following control is how we drive the two soft keys:
- MainMenu
When placed on a form, the two buttons directly under the screen become applicable. The mainmenu can only have two top-level menuitems, the Text of which is rendered on the screen buttons. The left root menuitem cannot have any child menuitems of its own and thus acts more like a button. The right root menu can have menuitems and hence may function as the normal menus we are accustomed to.
It is always good to cut code in order to understand a new platform, but I suggest you familiarise yourself with the platform philosophy before embarking on a project. Even if you are an experienced PPC developer, Smartphone is a new platform (in terms of UI - you can always use existing CF dlls without recompilation). I hope the above serves as a basis for understanding the philosophy and approach you should take for Smartphone development.
Other useful links for the newbie Smartphone developer:
Keys, menus, faq, msdn article, sp with cf primer, smartphone developer ng
The first thing to do is install the SmartPhone SDK. This will give you a new Smart Device Project type and an emulator of course (you may also get the Second Edition Emulator. Usually you choose the Pocket PC platform, now you should choose Smartphone (the only omission from the "project type" list is the "Non-graphical Application", a.k.a. "Console Application" on the Windows CE platform).
So the new project is created. The first thing you note is that the form is small (182w x 239h). In reality, the area you can manipulate is 176x180 pixels since you'll have a border, title bar and menu area. The menu area is actually the space for two soft keys (more on those in a moment). The second limitation we observe is the toolbox; device controls are already much fewer than the desktop, but they are further halved in numbers for Smartphone projects [VS2003 toolbox][VS2005 toolbox]. Later, I'll say a couple of words for some of the 14 controls (datagrid doesn't work) we have at our disposal.
At this point, it is worth stating the obvious: the SP has no touch screen and all interaction is via hardware buttons. The emulator [vs2003][whidbey] gives us some clues. Let's have a closer look at the buttons moving from the top downwards:
There are 3 sections:
1. LCD area
-Two button directly below the screen (a.k.a. soft keys).
2. Middle/center of the phone
-Two phone keys. Green for call and red for hungup.
-Below the call button there is a "home" button.
-Below the hungup button is a "Back" button.
-Between the 4 buttons just described is the rocker [Left, Right, Top, Down and Enter/Action]
3. Lower end of the phone
-Typical 12-button keypad found on all phones
In theory you could hook into any of these buttons and do whatever you want, but it makes sense to remember that the device's primary use is as a phone and also that MSFT has some guidelines for SP applications (some of which are enforced by the CF at runtime). For example the 12-button keypad can be used only for data entry (e.g. on a textbox); the call/hungup buttons (with the green & red phone icons) should be left alone, as should the home button (house icon). The back button navigates to the previous form (or to the previous application, if you are on the main form).
So let's look at the remainder buttons in correlation to the CF controls.
+ The following controls have no user interaction (other than displaying info, of course):
Label, Panel, PictureBox, ProgressBar, Timer, ImageList, VScrollBar, HScrollBar
+ The following 3 controls should be the only control on a single line (other than non-interactive controls mentioned above, of course):
- CheckBox
Up/Down move to the previous/next control on the form. Left/Right/Enter toggle the state.
- ComboBox
Up/Down move to the previous/next control on the form. Left/Right navigate through items in the combobox list. Enter brings up a full screen list of the items for selecting by scrolling with Up/Down.
- TextBox
Up/Down move to the previous/next control on the form. Left/Right moves the caret in the textbox. The Back button erases a character. If the textbox is Multiline=true, Enter brings up a full screen textbox (with scrollbars, if needed):
+ The following two controls must be the only (interactive) control on the form (there is no automatic way for them to pass focus to another control):
- ListView
Up/Down moves through the listview items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter generates the ItemActivate event.
- TreeView (must be the *only* control on the form)
Up/Down moves through the visible treenode items. Left/Right scrolls horizontally, if there is a scrollbar visible. Enter expands/collapses a treenode.
+ Given the absence of buttons, the two soft keys are the main mechanism of performing actions. The following control is how we drive the two soft keys:
- MainMenu
When placed on a form, the two buttons directly under the screen become applicable. The mainmenu can only have two top-level menuitems, the Text of which is rendered on the screen buttons. The left root menuitem cannot have any child menuitems of its own and thus acts more like a button. The right root menu can have menuitems and hence may function as the normal menus we are accustomed to.
It is always good to cut code in order to understand a new platform, but I suggest you familiarise yourself with the platform philosophy before embarking on a project. Even if you are an experienced PPC developer, Smartphone is a new platform (in terms of UI - you can always use existing CF dlls without recompilation). I hope the above serves as a basis for understanding the philosophy and approach you should take for Smartphone development.
Other useful links for the newbie Smartphone developer:
Keys, menus, faq, msdn article, sp with cf primer, smartphone developer ng
Labels: Mobile and Embedded
# posted by The Moth @ 10:25:00 AM
Tuesday, March 22, 2005
In the previous entry we identified how CF 2.0 does not support RTL on CE 5.0. We also defined what RTL support means.
Like with most features that CF does not support, we can work around this one with a bit of pinvoke. By reading this page on MSDN (thanks Chris Lorton) we see that, if we pinvoke SetWindowLong passing it the Control.Handle, we can change the RTL style.
In VS2005, to test if the above works, we populate a form with all the CF 2.0 controls and run the following method (e.g. call it from a button/menu click):
I have given you enough to run the test and check the results for yourselves, but here is my summary (lookout for screenshots at the end):
1. The following controls pass the test and meet the criteria as defined previously:
button, label, textbox, checkbox, radiobutton, progress bar, v/h scrollbar, form, tabcontrol, datetimepicker, monthview, toolbar, statusbar, listbox
2. The following fail
domainupdown, numericupdown - text part right aligns but buttons remain on the right
trackbar - shade issue (need to change value for effect to take place; refresh is not good enough)
treeview - When ShowLines=true, the lines are portrayed the wrong way round
listview - columns do not right-align (they are not affected at all by the style-change)
listview - resizing a column looks funny. You drag to the right but the listviewitems below move to the left and vice-versa
MainMenu - The top mainmenu items do not change order, although they are aligned to the right (and correctly after the toolbar) menus - when clicking on toolbarbutton with a menu OR a mainmenu to bring down its menuitems, the menuitems appear to the left of the mainmenu/toolbarbutton.
combobox - It appears ok RTL *but* clicking on the dropdown button results in the list appearing but the main combo area disappearing. Clicking elsewhere to take away the focus results in the combobox being drawn to the left (it moves left exactly its width in pixels). Repeating the process eventually moves the combobox outside the form area on the left (kind of funny, really).
3. Vertical Scrollbar issue [treeview, listview, listbox, multiline textbox etc]
Regardless of what is described above, all controls that can have a vertical scrollbar work only if the style is applied *prior* to a vertical scrollbar being displayed. If the vscrollbar is visible and the RTL style is changed, then the vscrollbar stops responding (freezes) and remains on the right.
Screenshots:
Good RTL
Not so good RTL
Bad RTL
Menu RTL
If you have a CE 5.0 device with CF 2.0 on it, feel free to try the exe (in fact, if from IE on your CE 5.0 device you browse to this link, you can run it)
Like with most features that CF does not support, we can work around this one with a bit of pinvoke. By reading this page on MSDN (thanks Chris Lorton) we see that, if we pinvoke SetWindowLong passing it the Control.Handle, we can change the RTL style.
In VS2005, to test if the above works, we populate a form with all the CF 2.0 controls and run the following method (e.g. call it from a button/menu click):
// Call this method with this.ChangeToRTL(this)To test the results you need a CE 5.0 device (or simply get the CE 5.0 emulator as described here).
private void ChangeToRTL(Control c) {
this.ApplyStyle(c);
foreach (Control c2 in c.Controls) {
this.ChangeToRTL(c2);
}
}
private void ApplyStyle(Control c) {
Int32 lS = GetWindowLong(c.Handle, GWL_EXSTYLE);
lS |= WS_EX_LAYOUTRTL;
SetWindowLong(c.Handle, GWL_EXSTYLE, lS);
c.Invalidate();
}
I have given you enough to run the test and check the results for yourselves, but here is my summary (lookout for screenshots at the end):
1. The following controls pass the test and meet the criteria as defined previously:
button, label, textbox, checkbox, radiobutton, progress bar, v/h scrollbar, form, tabcontrol, datetimepicker, monthview, toolbar, statusbar, listbox
2. The following fail
domainupdown, numericupdown - text part right aligns but buttons remain on the right
trackbar - shade issue (need to change value for effect to take place; refresh is not good enough)
treeview - When ShowLines=true, the lines are portrayed the wrong way round
listview - columns do not right-align (they are not affected at all by the style-change)
listview - resizing a column looks funny. You drag to the right but the listviewitems below move to the left and vice-versa
MainMenu - The top mainmenu items do not change order, although they are aligned to the right (and correctly after the toolbar) menus - when clicking on toolbarbutton with a menu OR a mainmenu to bring down its menuitems, the menuitems appear to the left of the mainmenu/toolbarbutton.
combobox - It appears ok RTL *but* clicking on the dropdown button results in the list appearing but the main combo area disappearing. Clicking elsewhere to take away the focus results in the combobox being drawn to the left (it moves left exactly its width in pixels). Repeating the process eventually moves the combobox outside the form area on the left (kind of funny, really).
3. Vertical Scrollbar issue [treeview, listview, listbox, multiline textbox etc]
Regardless of what is described above, all controls that can have a vertical scrollbar work only if the style is applied *prior* to a vertical scrollbar being displayed. If the vscrollbar is visible and the RTL style is changed, then the vscrollbar stops responding (freezes) and remains on the right.
Screenshots:
Good RTL
Not so good RTL
Bad RTL
Menu RTL
If you have a CE 5.0 device with CF 2.0 on it, feel free to try the exe (in fact, if from IE on your CE 5.0 device you browse to this link, you can run it)
Labels: Mobile and Embedded
# posted by The Moth @ 2:48:00 PM
Thursday, March 17, 2005
In some places in the world they read and write from right to left (RTL). Prime examples of such languages are hebrew and arabic. As a software developer, if your market extends to such users, you should support RTL in your application. Unlike support for a LTR language, there are additional things your windows app must do. For .NET apps this includes using the Control.RightToLeft property.
For the Compact Framework the story is less straightforward. You see, the CF is a subset of the .NET Framework that runs on Windows CE based devices. Windows CE 4.x and previous versions do not support RTL (since all current Pocket PC devices are based on the CE 3.x/4.2 operating system, by definition they do not support RTL either). There may be 3rd party solutions available, but I am not aware of any. It would be a nice touch if the CF implemented RTL support without support from the OS (i.e. it could simulate it) however that would probably mean that the windows controls would not be just thin wrappers of the OS equivalent and hence performance would suffer - not to mention framework size.
The OS story becomes much better with the next version of Windows CE. In a sentence, CE 5.0 supports RTL :-)
For devs with their own platform this means migrating from 4.2 to 5.0. (for devs of PPCs [Windows Mobile for Pocket PC] or SPs [Windows Mobile for SmartPhone], my *guess* is you have to wait for a next version of Windows Mobile which if based on CE 5.0 could expose the underlying OS support).
Since CE 5.0 supports RTL and since Compact Framework 2.0 *only* runs on CE 5.0 (and WM2003 for PPC), I'd forgive you for making the logical jump that CF 2.0 exposes Control.RightToLeft - think again. That's right, the infamous "postponed"!
Before we go off in a sulk, it is worth capturing what we mean by RTL support:
1. CheckBoxes (the square bit) and RadioButtons (the circle bit) should appear on the left [there is no CheckAlign property on CF]
2. UpDown buttons (e.g. NumericUpDown and DomainUpDown) should appear on left
3. Controls with vertical scrollbar (e.g. TreeView, ListView, ListBox, multiline TextBox etc) should render the scrollbar on the left
4. Wherever there is text that is naturally left-aligned, it should be right-aligned (e.g. *any* control with .Text property such as Form or .Items such as ListView)
5. Menus, ToolBar buttons and form buttons (i.e. max/min/close buttons, control box) must be mirrored (right aligned)
6. ProgressBar, TrackBar and HScrollBar should start from right.
and a more subtle one
7. Shadows of controls should appear on the left. If you haven't noticed this before, have a closer look at button/scrollbar/trackbar etc: they have a white border top & left and dark border bottom & right. The left & right shades must be switched when RTL applies.
Next time we'll see what we can do with CF 2.0 to support RTL on CE 5.0. I'll include screenshots and details of which controls (based on the November CTP) pose insurmountable problems!
For the Compact Framework the story is less straightforward. You see, the CF is a subset of the .NET Framework that runs on Windows CE based devices. Windows CE 4.x and previous versions do not support RTL (since all current Pocket PC devices are based on the CE 3.x/4.2 operating system, by definition they do not support RTL either). There may be 3rd party solutions available, but I am not aware of any. It would be a nice touch if the CF implemented RTL support without support from the OS (i.e. it could simulate it) however that would probably mean that the windows controls would not be just thin wrappers of the OS equivalent and hence performance would suffer - not to mention framework size.
The OS story becomes much better with the next version of Windows CE. In a sentence, CE 5.0 supports RTL :-)
For devs with their own platform this means migrating from 4.2 to 5.0. (for devs of PPCs [Windows Mobile for Pocket PC] or SPs [Windows Mobile for SmartPhone], my *guess* is you have to wait for a next version of Windows Mobile which if based on CE 5.0 could expose the underlying OS support).
Since CE 5.0 supports RTL and since Compact Framework 2.0 *only* runs on CE 5.0 (and WM2003 for PPC), I'd forgive you for making the logical jump that CF 2.0 exposes Control.RightToLeft - think again. That's right, the infamous "postponed"!
Before we go off in a sulk, it is worth capturing what we mean by RTL support:
1. CheckBoxes (the square bit) and RadioButtons (the circle bit) should appear on the left [there is no CheckAlign property on CF]
2. UpDown buttons (e.g. NumericUpDown and DomainUpDown) should appear on left
3. Controls with vertical scrollbar (e.g. TreeView, ListView, ListBox, multiline TextBox etc) should render the scrollbar on the left
4. Wherever there is text that is naturally left-aligned, it should be right-aligned (e.g. *any* control with .Text property such as Form or .Items such as ListView)
5. Menus, ToolBar buttons and form buttons (i.e. max/min/close buttons, control box) must be mirrored (right aligned)
6. ProgressBar, TrackBar and HScrollBar should start from right.
and a more subtle one
7. Shadows of controls should appear on the left. If you haven't noticed this before, have a closer look at button/scrollbar/trackbar etc: they have a white border top & left and dark border bottom & right. The left & right shades must be switched when RTL applies.
Next time we'll see what we can do with CF 2.0 to support RTL on CE 5.0. I'll include screenshots and details of which controls (based on the November CTP) pose insurmountable problems!
Labels: Mobile and Embedded
# posted by The Moth @ 11:38:00 AM
Sunday, February 27, 2005
I would like CF development to be accessible to *everyone*. No personal gain in that statement (I've always had an MSDN universal subscription and I don't plan, in the near future, to write in anything other than C# and VB), I just want the platform to gain more developers/users.
It is sad that there is no SDK for CF 1.0 and that VS.NET 2003 Professional and above is required. Even though CF 2.0 comes with an SDK and VS2005 Standard is adequate, I am still not happy that the Express editions will not support Smart Device projects.
On the programming language front, dotnet is about multiple languages being able to target the platform (20+ on the desktop). On the other hand, CF only allows C# and VB.NET! No J#, no managed C++ etc. If you are thinking "it all compiles down to IL at the end of the day", unfortunately that is not enough: some IL instructions such as localloc and calli are not supported and design time support is more complex.
So, in the context of the above, I was disappointed to read this post on the Delphi blog (via Tim Anderson).
Will an MSFT reply be forthcoming?
It is sad that there is no SDK for CF 1.0 and that VS.NET 2003 Professional and above is required. Even though CF 2.0 comes with an SDK and VS2005 Standard is adequate, I am still not happy that the Express editions will not support Smart Device projects.
On the programming language front, dotnet is about multiple languages being able to target the platform (20+ on the desktop). On the other hand, CF only allows C# and VB.NET! No J#, no managed C++ etc. If you are thinking "it all compiles down to IL at the end of the day", unfortunately that is not enough: some IL instructions such as localloc and calli are not supported and design time support is more complex.
So, in the context of the above, I was disappointed to read this post on the Delphi blog (via Tim Anderson).
Will an MSFT reply be forthcoming?
Labels: Mobile and Embedded
# posted by The Moth @ 7:41:00 AM
Wednesday, February 23, 2005
No doubt you are familiar with the System.Threading.ThreadPool (if not, go learn about it now!). The Compact Framework implementation only offers a single method: QueueUserWorkItem(WaitCallback, Object). Basically, every time you call this method it will call you back on a different thread, passing back to you the state object you gave it, so you can run your background work. Once the background work is finished (i.e. the method returns), the thread is then either reused in a future call or is removed from the pool (after a undefined interval). The advantage over explicitly creating threads is obvious in such a thread-reuse scenario (less context switching, no thread creation/destruction overhead each time, ease of use).
Internally, the NETCF ThreadPool is built on the System.Threading.Timer (whose core implementation is in native code). In other words starting a one shot timer with
Apart from the different implementations, the desktop and CF ThreadPool have other differences.
1. The documentation states that explicitly using a thread is a better alternative to the ThreadPool for lengthy operations i.e. use the ThreadPool for short-lived tasks. One of the reasons it advises this is because the desktop implementation has a ThreadPool limit of 25 per process (so, for example, you can imagine deadlock situations if you starve the ThreadPool of its 25 threads and e.g. two of them are waiting to acquire the same resource). However, the NETCF 1.0 ThreadPool has a limit of 256 (treat that as if there was no limit; for a laugh, I tried testing the limit and my device stopped responding around ~150). Note that CF 2.0 rectifies this by setting the limit to 25, bringing parity with the desktop. On the desktop with .NET 1.1 you can change it if you really try hard and with .NET 2.0 there is even a method (SetMaxThreads). I am not sure if we will see this method in the CF 2.0 RTM, but for the November CTP you can control the number of threads via the registry:
2. The desktop's ThreadPool threads are all background. Since the CF 1.0 does not support background threads, the difference is obvious. As a reminder, a non-background thread can keep your process up even if the main (UI) thread has exited. Since CF 2.0 supports Thread.IsBackground, the ThreadPool threads will return true for that property.
3. ThreadPool threads, like other managed threads, are created at the default priority of Normal (251 in WinCE terms). I have discussed previously about "Threads and ThreadPriority with the .NET Compact Framework". If (against my advice in that post) you change the priority of ThreadPool threads (which btw can only be done in the callback), you will find that the priority may not be reverted when the thread is returned to the ThreadPool (MSFT quote). In other words, future uses of the ThreadPool could run on that thread with whatever priority you gave it in a different context (dangerous!). This is not true for the Full Framework and, fortunately, CF 2.0 brings parity with the desktop.
So we can see all the differences between CF 1.0 and Full Fx 1.1, but we also see how CF 2.0 eliminates them.
Finally, CF 1.0 does not support Control.BeginInvoke but CF 2.0, like the desktop, does. BeginInvoke indeed uses threads from the ThreadPool on both platforms.
Internally, the NETCF ThreadPool is built on the System.Threading.Timer (whose core implementation is in native code). In other words starting a one shot timer with
dueTime of 0 is the same as queuing a work item with the ThreadPool. Clearly using the ThreadPool is the preferred choice (in other words don't use the Threading.Timer just for going async, rather use it in scenarios where timing is truly required).Apart from the different implementations, the desktop and CF ThreadPool have other differences.
1. The documentation states that explicitly using a thread is a better alternative to the ThreadPool for lengthy operations i.e. use the ThreadPool for short-lived tasks. One of the reasons it advises this is because the desktop implementation has a ThreadPool limit of 25 per process (so, for example, you can imagine deadlock situations if you starve the ThreadPool of its 25 threads and e.g. two of them are waiting to acquire the same resource). However, the NETCF 1.0 ThreadPool has a limit of 256 (treat that as if there was no limit; for a laugh, I tried testing the limit and my device stopped responding around ~150). Note that CF 2.0 rectifies this by setting the limit to 25, bringing parity with the desktop. On the desktop with .NET 1.1 you can change it if you really try hard and with .NET 2.0 there is even a method (SetMaxThreads). I am not sure if we will see this method in the CF 2.0 RTM, but for the November CTP you can control the number of threads via the registry:
HKLM\Software\Microsoft\.NETCompactFramework\ThreadPool\MaxThreads2. The desktop's ThreadPool threads are all background. Since the CF 1.0 does not support background threads, the difference is obvious. As a reminder, a non-background thread can keep your process up even if the main (UI) thread has exited. Since CF 2.0 supports Thread.IsBackground, the ThreadPool threads will return true for that property.
3. ThreadPool threads, like other managed threads, are created at the default priority of Normal (251 in WinCE terms). I have discussed previously about "Threads and ThreadPriority with the .NET Compact Framework". If (against my advice in that post) you change the priority of ThreadPool threads (which btw can only be done in the callback), you will find that the priority may not be reverted when the thread is returned to the ThreadPool (MSFT quote). In other words, future uses of the ThreadPool could run on that thread with whatever priority you gave it in a different context (dangerous!). This is not true for the Full Framework and, fortunately, CF 2.0 brings parity with the desktop.
So we can see all the differences between CF 1.0 and Full Fx 1.1, but we also see how CF 2.0 eliminates them.
Finally, CF 1.0 does not support Control.BeginInvoke but CF 2.0, like the desktop, does. BeginInvoke indeed uses threads from the ThreadPool on both platforms.
Labels: Mobile and Embedded
# posted by The Moth @ 2:57:00 PM
Tuesday, February 22, 2005
Two years ago I asked the question:
The simple idea of overlaying the listview with a vscrollbar works great and is an important technique for CF lists with a large number of items (for memory and performance improvements). What I am trying to say is that, rather than populate your list with XXX number of items, you need only populate the visible (e.g. 8-16) items and when the user scrolls down populate accordingly the remainder (since you know the top index and the number of visible items at any one time).
The same principle, but with a twist, applies when the listviewitems need to be refreshed/updated every so often. E.g. my listviews get populated with information retrieved from the network. By knowing which items are visible, I avoid refreshing the ones that are not, resulting in faster user interaction and less noise on the network. By also wrapping the refresh timer into the container control, the rest of the client code is oblivious to how the list gets populated.
Finally, you could offer explicit pageup/pagedown buttons (since you are in programmatic control of the scrolling). A screen shot of what such a listview looks like see this (the statusbar of that screenshot is a whole different story :-).
Enjoy the code from the link at the top of this post and if you need the same for a ListControl rather than a listview, follow the link from here.
"I cannot find an event to catch when the user scrolls the scrollbar? The goal is to detect when the listview is scrolled and then get all visible items (or just the top one and work my way down since I know how many can be visible at a time) and do some function..."I then replied to my own post.
The simple idea of overlaying the listview with a vscrollbar works great and is an important technique for CF lists with a large number of items (for memory and performance improvements). What I am trying to say is that, rather than populate your list with XXX number of items, you need only populate the visible (e.g. 8-16) items and when the user scrolls down populate accordingly the remainder (since you know the top index and the number of visible items at any one time).
The same principle, but with a twist, applies when the listviewitems need to be refreshed/updated every so often. E.g. my listviews get populated with information retrieved from the network. By knowing which items are visible, I avoid refreshing the ones that are not, resulting in faster user interaction and less noise on the network. By also wrapping the refresh timer into the container control, the rest of the client code is oblivious to how the list gets populated.
Finally, you could offer explicit pageup/pagedown buttons (since you are in programmatic control of the scrolling). A screen shot of what such a listview looks like see this (the statusbar of that screenshot is a whole different story :-).
Enjoy the code from the link at the top of this post and if you need the same for a ListControl rather than a listview, follow the link from here.
Labels: Mobile and Embedded
# posted by The Moth @ 2:09:00 PM
Monday, February 21, 2005
Over the last 2-3 weeks I have discussed on 3 completely separate occasions the subject of serving web pages from a CF application on a Windows CE device. Since ASP.NET is not supported on the Compact Framework, the question I get is "how to" and my answer is typically along these lines:
There are 3+1 options
1. Native Only
2. Managed Only
3. Hybrid
4. Wait for CF 3.0 (?)
1. The first option is basically not an option if you are determined to leverage your business logic, which is already written in C# or VB.NET. However, I always mention it because I think it is important to understand what the out-of-the-box options are on Windows CE. You can find them here.
2. The second option basically means writing your own web server (and hence not taking advantage of IIS on WinCE). This either makes faces drop ("Are you serious?") or produces smiles ("I am a control freak anyway so having complete command of how the web server works sounds great!"). Either way, you don't have to start from scratch, as others have been there before (use them as inspiration or just rip off their implementations).
a) Port cassini
b) Use the results of the Monash project
c) Port the ASP.NET MONO implementation (not aware of any *public* project that has achieved it, but there are some guys that have done it (ended up at ~1300KB) and if they want to go public with it I am sure they will - I cannot say anything else, I'm afraid)
3. If you followed my link when discussing the first option, you know that on WinCE you typically write an ISAPI extension for serving pages; imagine if from the ISAPI extension entry point (HttpExtensionProc) you could start talking to a managed dll that did the work for generating and returning the pages. Alas, unlike the desktop, hosting the runtime is not an option with NETCF. So what is it that I always offer as a poor alternative for hosting the runtime? Inter-Process Communication! So, to summarise the hybrid approach with CF 1.0/2.0: Write some C code that seats between IIS and a managed exe communicating via any IPC mechanism you see fit.
4. This is not a serious option for two reasons: Who in their right mind will wait for CF 3.0 when even CF 2.0 is not released yet (does anybody work for a company that looks that far into the future)? The second reason this is not a serious option is because nobody knows what CF 3.0 will offer! My hope is that the CF team will listen to requests on allowing us to host the CLR (this will make option 3 a breeze) or even better offer ASP.NETcf (and then I woke up :-)
Expect to read more on this topic here in the future, as I am looking at this feature for one of our products.
There are 3+1 options
1. Native Only
2. Managed Only
3. Hybrid
4. Wait for CF 3.0 (?)
1. The first option is basically not an option if you are determined to leverage your business logic, which is already written in C# or VB.NET. However, I always mention it because I think it is important to understand what the out-of-the-box options are on Windows CE. You can find them here.
2. The second option basically means writing your own web server (and hence not taking advantage of IIS on WinCE). This either makes faces drop ("Are you serious?") or produces smiles ("I am a control freak anyway so having complete command of how the web server works sounds great!"). Either way, you don't have to start from scratch, as others have been there before (use them as inspiration or just rip off their implementations).
a) Port cassini
b) Use the results of the Monash project
c) Port the ASP.NET MONO implementation (not aware of any *public* project that has achieved it, but there are some guys that have done it (ended up at ~1300KB) and if they want to go public with it I am sure they will - I cannot say anything else, I'm afraid)
3. If you followed my link when discussing the first option, you know that on WinCE you typically write an ISAPI extension for serving pages; imagine if from the ISAPI extension entry point (HttpExtensionProc) you could start talking to a managed dll that did the work for generating and returning the pages. Alas, unlike the desktop, hosting the runtime is not an option with NETCF. So what is it that I always offer as a poor alternative for hosting the runtime? Inter-Process Communication! So, to summarise the hybrid approach with CF 1.0/2.0: Write some C code that seats between IIS and a managed exe communicating via any IPC mechanism you see fit.
4. This is not a serious option for two reasons: Who in their right mind will wait for CF 3.0 when even CF 2.0 is not released yet (does anybody work for a company that looks that far into the future)? The second reason this is not a serious option is because nobody knows what CF 3.0 will offer! My hope is that the CF team will listen to requests on allowing us to host the CLR (this will make option 3 a breeze) or even better offer ASP.NETcf (and then I woke up :-)
Expect to read more on this topic here in the future, as I am looking at this feature for one of our products.
Labels: Mobile and Embedded
# posted by The Moth @ 9:03:00 AM
Tuesday, February 15, 2005
Alternative title: "Discovery of the day, link.exe"
Recall how at the Beta 1 timeframe we saw CF 2.0 add support for multi-file assemblies? If not, please go and read it, as the content here builds on that (here based on November CTP).
a) Follow steps 1, 2 and 3 from that post (adjusting the path to [drive letter]\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\Debugger\BCL).
b) Change step 4 by typing
You now have two files (Form1Mixed.netmodule & ProgramMixed.netmodule) but, instead of one of them being an
c) Now, enter the following at the command line:
The result is a single executable that contains the IL from both netmodules (that you recall were written in two different languages)! And we didn't even have to use ilmerge.
[This blog entry was inspired by this post]
Recall how at the Beta 1 timeframe we saw CF 2.0 add support for multi-file assemblies? If not, please go and read it, as the content here builds on that (here based on November CTP).
a) Follow steps 1, 2 and 3 from that post (adjusting the path to [drive letter]\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\Debugger\BCL).
b) Change step 4 by typing
/t:module just before ProgramMixed.csYou now have two files (Form1Mixed.netmodule & ProgramMixed.netmodule) but, instead of one of them being an
exe and the other a netmodule, they are both netmodules. Recall from step 5 that running the exe would work only if the netmodule accompanied the exe (hence the talk of multi-file assemblies).c) Now, enter the following at the command line:
link /LTCG /verbose /entry:MixedLanguages.Program.Main /out:SingleFile.exe Form1Mixed.netmodule ProgramMixed.netmodule /subsystem:windowsThe result is a single executable that contains the IL from both netmodules (that you recall were written in two different languages)! And we didn't even have to use ilmerge.
[This blog entry was inspired by this post]
Labels: Mobile and Embedded
# posted by The Moth @ 1:25:00 PM
Tuesday, February 08, 2005
Mike Zintel has a follow up to his previous post (the one which made me throw the rattle out of the pram). I'll give you a few minutes to go read it if you promise to come back.
Is it shocking or what?
Headless device support is close to being dropped!
Anyone got a helmet? I'll need it as I inform my team that the business logic wrapped in my .NET code cannot be used on our new product and we have to rewrite it in eVC! Can you guess the response? Perhaps something along the lines of: "Why didn't we do that in the first place?"
Is it shocking or what?
Headless device support is close to being dropped!
Anyone got a helmet? I'll need it as I inform my team that the business logic wrapped in my .NET code cannot be used on our new product and we have to rewrite it in eVC! Can you guess the response? Perhaps something along the lines of: "Why didn't we do that in the first place?"
Labels: Mobile and Embedded
# posted by The Moth @ 3:02:00 AM
Friday, February 04, 2005
We haven't even got CF 2.0 yet and Mike Zintel is talking about CF 3.0... fantastic! Go let the team know what you want.
The focus for CF 3.0 will be
.NET Compact Framework is not only about mobile devices!
I understand that the focus is on Windows Mobile devices but *PLEASE* give some thought to custom-WinCE-based devices. Vanilla CE devices. Non-PPC devices. I don't care what you call it, but you know what I am talking about.
There are devices fixed on a wall with a permanent network connection. Do you want such a device to run Windows CE? What development language do you expect me to use, C++? If that is the answer, I don't have a problem, but just come out and say it! I can tell you that NETCF 1.0 is perfectly capable of satisfying the initial need, but when trying to take an application to the next step... brick walls. Example:
- Web server & Web Services (*not* client).
Give me ASP.NET on the device! Componentize it so if you don't want PPCs to suffer the footprint, they can opt out.
You should be striving for CF 3.0 to be the sensible choice for WinCE development. Is there any *new* project for the PC starting its life based on C++? Madness, in my view; dotnet or Java are the only sensible choices. Do the same for Windows CE. Today most WinCE old hats still cringe at the sound of CF. Tomorrow with CF 2.0 it will get better. With CF 3.0, unless I am writing drivers, choosing C++ should be a laughable choice. Magneto comes with managed platform interfaces; Longhorn will come with managed platform interfaces; are we ever going to see that in the core WinCE OS?
If I hear or read one more time that "NETCF = mobile battery-powered occasionally-connected device", I'll unscrew my unit off the wall, pull the ethernet & power cables out and hit somebody on the head with it!
Not to finish on a violent tone, let me summarise:
1. ASP.NET on the device (implies the ability to host the runtime)
2. Parity with the desktop. Give me the .NET Framework on the device and componentise it so OEMs can opt out.
3. Throw a bone to non-PPC developers
The focus for CF 3.0 will be
"making it easier to deal with transiently connected networks."Only a fool would argue that it is not an important area and I will not be that fool; however, I would like to offer my wish list leading with a statement (warning, rant ahead):
.NET Compact Framework is not only about mobile devices!
I understand that the focus is on Windows Mobile devices but *PLEASE* give some thought to custom-WinCE-based devices. Vanilla CE devices. Non-PPC devices. I don't care what you call it, but you know what I am talking about.
There are devices fixed on a wall with a permanent network connection. Do you want such a device to run Windows CE? What development language do you expect me to use, C++? If that is the answer, I don't have a problem, but just come out and say it! I can tell you that NETCF 1.0 is perfectly capable of satisfying the initial need, but when trying to take an application to the next step... brick walls. Example:
- Web server & Web Services (*not* client).
Give me ASP.NET on the device! Componentize it so if you don't want PPCs to suffer the footprint, they can opt out.
You should be striving for CF 3.0 to be the sensible choice for WinCE development. Is there any *new* project for the PC starting its life based on C++? Madness, in my view; dotnet or Java are the only sensible choices. Do the same for Windows CE. Today most WinCE old hats still cringe at the sound of CF. Tomorrow with CF 2.0 it will get better. With CF 3.0, unless I am writing drivers, choosing C++ should be a laughable choice. Magneto comes with managed platform interfaces; Longhorn will come with managed platform interfaces; are we ever going to see that in the core WinCE OS?
If I hear or read one more time that "NETCF = mobile battery-powered occasionally-connected device", I'll unscrew my unit off the wall, pull the ethernet & power cables out and hit somebody on the head with it!
Not to finish on a violent tone, let me summarise:
1. ASP.NET on the device (implies the ability to host the runtime)
2. Parity with the desktop. Give me the .NET Framework on the device and componentise it so OEMs can opt out.
3. Throw a bone to non-PPC developers
"...pretty please, with sugar on top..."
Labels: Mobile and Embedded
# posted by The Moth @ 3:26:00 PM
Wednesday, February 02, 2005
It seems that every other week some blogger somewhere discovers the great new VS2005 feature: custom Debugger Visualizers. How many of you realise this doesn't work for Smart Device Projects?
For example, if in a Compact Framework 2.0 project you try my DV sample you'll see the option, but selecting it produces the following error:
---------------------------
Microsoft Visual Studio
---------------------------
Could not load this custom viewer.
---------------------------
OK
---------------------------
I know there is no need to encourage you too much to go make the product better :-)
For example, if in a Compact Framework 2.0 project you try my DV sample you'll see the option, but selecting it produces the following error:
---------------------------
Microsoft Visual Studio
---------------------------
Could not load this custom viewer.
---------------------------
OK
---------------------------
I know there is no need to encourage you too much to go make the product better :-)
Labels: Mobile and Embedded
# posted by The Moth @ 2:14:00 PM
Monday, January 31, 2005
Every .NET developer is familiar with platform invocation services (PInvoke), the ability to call native functions declared in dlls via the DllImport attribute. In the early .NET days it was common to see queries about specific API declarations, but 4 years down the road you would have thought people would stop asking and instead use the ready-made ones easily found all over the web. This blog entry is proof of the opposite and it will serve as my pointer next time someone requests a particular Win32 DllImport declaration.
First place to go is the pinvoke wiki (tip: check out the Helpful tools). This was started by Adam Nathan (author of the only COM Interop book you need, which covers interoperability in general and not just COM).
From a Compact Framework perspective, the first place to go is the OpenNETCF source. Search it for the API name you are after and steal the C# DllImport declaration :-)
In addition to the above, since I often refer to a Win32Api class in both newsgroup and blog posts, I include here a link to my own Win32Api.vb (as the extension suggests, it is in VB.NET so the C#-challenged amongst you may prefer it)
Win32Api is a class with the dllimports that I use in my projects (exposed as Shared methods). It started life years ago when I was doing desktop development and was subsequently morphed to support both compact and Full frameworks (hint: look for the FULL_FRAME compilation constant). I don't claim to have crafted every declaration myself, quite the opposite, half of them are probably lifted from ready made declarations found on the web :-)
First place to go is the pinvoke wiki (tip: check out the Helpful tools). This was started by Adam Nathan (author of the only COM Interop book you need, which covers interoperability in general and not just COM).
From a Compact Framework perspective, the first place to go is the OpenNETCF source. Search it for the API name you are after and steal the C# DllImport declaration :-)
In addition to the above, since I often refer to a Win32Api class in both newsgroup and blog posts, I include here a link to my own Win32Api.vb (as the extension suggests, it is in VB.NET so the C#-challenged amongst you may prefer it)
Win32Api is a class with the dllimports that I use in my projects (exposed as Shared methods). It started life years ago when I was doing desktop development and was subsequently morphed to support both compact and Full frameworks (hint: look for the FULL_FRAME compilation constant). I don't claim to have crafted every declaration myself, quite the opposite, half of them are probably lifted from ready made declarations found on the web :-)
Labels: Mobile and Embedded
# posted by The Moth @ 4:01:00 PM
Friday, January 28, 2005
For those that write Compact Framework applications for custom CE devices, the VS emulators are not as useful as they are for PPC development.
We always advise people to get an SDK from the device manufacturer – or even better an actual device to test against. I have been lucky to be playing with a real device from day 1, never having to use the emulator for real development. If you are trying to generate an SDK from Platform Builder, you may find that it is not easy to get it right first time, and more often than not you end up with a black-screen emulator that VS.NET 2003 cannot connect to. The fun bit is where the emulator works OK in eVC, and then when you try to use it in VS, not only it doesn't work but it actually hoses the emulator in such a way that it stops working in eVC, but I digress.
So I thought it useful to include here the *exact* steps that work for us when building (and exporting) an SDK for use in both VS and eVC. Enjoy :-)
1. Make a new platform based on Emulator BSP
2. Configure the image as you require (make sure the image includes .NET Compact Framework, toolhelp.dll and Smart Device Authentication Utility)
3. Make sure that KITL support is disabled in the image (i.e. when you select Platform -> Settings -> Build Options, the only thing that should be checked is "Enable EBOOT Space in Memory")
4. Build the Emulator image
5. Configure the SDK
On the emulation tab - this is up to you e.g. memory size = 64MB and screen size = 320x240, 8 bit
On the transports tab - Make sure Microsoft KITL Transport is *not* checked, set ActiveSync as the default
On the Development Languages Tab - Select everything (so the same SDK will work in eVC++ and VS.NET)
On the Startup Servers tab - Make sure they're all selected and that ActiveSync is the default.
6. Build the SDK
We always advise people to get an SDK from the device manufacturer – or even better an actual device to test against. I have been lucky to be playing with a real device from day 1, never having to use the emulator for real development. If you are trying to generate an SDK from Platform Builder, you may find that it is not easy to get it right first time, and more often than not you end up with a black-screen emulator that VS.NET 2003 cannot connect to. The fun bit is where the emulator works OK in eVC, and then when you try to use it in VS, not only it doesn't work but it actually hoses the emulator in such a way that it stops working in eVC, but I digress.
So I thought it useful to include here the *exact* steps that work for us when building (and exporting) an SDK for use in both VS and eVC. Enjoy :-)
1. Make a new platform based on Emulator BSP
2. Configure the image as you require (make sure the image includes .NET Compact Framework, toolhelp.dll and Smart Device Authentication Utility)
3. Make sure that KITL support is disabled in the image (i.e. when you select Platform -> Settings -> Build Options, the only thing that should be checked is "Enable EBOOT Space in Memory")
4. Build the Emulator image
5. Configure the SDK
On the emulation tab - this is up to you e.g. memory size = 64MB and screen size = 320x240, 8 bit
On the transports tab - Make sure Microsoft KITL Transport is *not* checked, set ActiveSync as the default
On the Development Languages Tab - Select everything (so the same SDK will work in eVC++ and VS.NET)
On the Startup Servers tab - Make sure they're all selected and that ActiveSync is the default.
6. Build the SDK
Labels: Mobile and Embedded
# posted by The Moth @ 12:58:00 PM
Copyright © Daniel Moth
