The Moth

This evening was the time for yet another local VBUG meeting. This time the subject was SharePoint (you know, web parts and all that). I have not touched ASP.NET since 2001 (and even then it was only for a month writing proof of concept projects) and before tonight I couldn’t spell SharePoint, so I went with a total newbie mindset.

Jonathan with his "code monkey" (Nick Francis) gave a good show and now I feel I can talk about the subject a bit. What was more interesting with today’s session is that at times it drifted into a chat and quite a few “asides”. Not sure what the others made of that, but I think that is what local user groups are all about: free-form exchange of ideas.

At the end I had a chat with Ian (organiser) and arranged to hold a session for VBUG either in Brighton (March) or Horsham (April). Full details will be on this blog nearer to the time, but you can guess what the subject will be, right?

It was yesterday 18:00 GMT; you missed it! Why? I have told you about these before!

Every so often I come across a blog post where the owner asks a question to their readers. Most of the time they would get a faster response if they posted to the relevant newsgroup. I realise that some people don't like using newsgroups, but a chat is more direct. There is no chance of you posting something and being ignored, you are exposed to less people, and your name is not captured in any archives (I am just randomly eliminating possible reasons that people don't post at newsgroups). Every .NET area has its own chats, so there are loads to choose from. So follow my links above and take note. I hope to see you there next time.

Oh, I almost forgot, apologies to the two people whose private messages I ignored, but as you could tell I was busy answering questions. I apologise assuming they are readers of this blog (otherwise, s*d them, I don't like unsolicited messages (of the "HY" variety)... only joking folks, *do* feedback to me whatever is on your mind... just save the generic questions for the newsgroup and the chats :-).

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?"

- Shawn Burke wraps up the "shipping source" discussion.
I wonder: If we do reach a stage where the framework code is available for stepping into, will VB developers ask for a VB version of the code (or will the last few that resist learning how to at least read C# give in?

- Jono turns his blog entry into a job board for CF developers and recruiters
(of course, if you are looking for NETCF consulting you should start here).

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

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

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 :-)

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 :-)

- "You should log unhandled exceptions, not just swallow them!" I have met many that refuse to adopt my advice (usually the type that love On Error Resume Next). If I can't convince you of the opposite, maybe this blog entry will.

- Some obvious, some not so obvious; overall a great post that brings together in one place the wisdom of when to go async and related advice

- Some humour on Unit testing :-D
(if you are a sensitive TDD advocate, keep your knickers on please, it is only a joke!)

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

In a Sentence (or five)
When NETCF controls are created they have a default Font. You would expect the default Font to be picked from the platform (operating system) default Font. However, that is not the case and instead they start of with Tahoma. This cannot be defended as a design choice so it must be a bug! Vote for it to be fixed (the bug is present in CF 1.0 and CF 2.0).

Repro Steps
1. Create a new form
2. Add a button to it (or any other control including custom ones)
3. In the button event handler put the following code:
MessageBox.Show(this.Font.Name,Button1.Font.Name); //C#
MessageBox.Show(Me.Font.Name,Button1.Font.Name) ' VB
4. You see Tahoma, Tahoma (assuming your system default is Tahoma)

5. Change the system's default Font to Arial or Courier New (or some other Font on your unit)
HKLM\System\GDI\SysFnt\Nm
HKLM\System\GWE\Menu\BarFnt\Nm
HKLM\System\GWE\Menu\popFnt\Nm

6. Reset the unit and run the test again
7. You see Arial, Tahoma (they should both be Arial - or whatever the system default is)

Why Fix the Bug
1. 99.99% of controls never have their Font changed by the developer; in fact the only times we change font is for size or style, not name. Hence we expect the Font to be the system default.
2. If we run an app like that on a unit where the default font has changed, it will not pick it up.
3. eVC defaults to system Font so there is no precedence of hardcoding default fonts
4. As the repro steps show, there is inconsistency within the implementation itself. The title bar caption/text the default font whereas the other controls use the hardcoded Tahoma
5. Further inconsistency is that the menu fonts are picked up properly. Even the built-in error handler dialog picks up the correct Font.
6. Changing the Font of every control in Smart Device projects is more cumbersome than the desktop since changing the Font of a container (e.g. Form, Panel) does not propagate to the children controls (no Ambient properties on CF)

How I came across it
Due to other reasons, we have to change the default font of our platform to Arial. Half the screens look odd and I now have to go and explicitly change the Font for all controls. Yes I know "poor me" but that is not the point. Next time we decide to change the default Font I will have to change the hardcoded values since the NETCF controls are not smart enough to pick the default.