The Moth

This blog entry serves as a description of what I call a bug (others might call it a limitation by design). The post after this will describe the workaround solution.

We are all familiar with the Toolbar and ToolBarButtons, right? There is different behaviour in this area of the OS, depending on the platform. On CE they appear at the top, whereas on PPCs they are at the bottom of the screen (no problem so far, but there is more). ToolBarButtons in .NET have a Style property, which by default is ToolBarButtonStyle.PushButton and hence we get normal buttons that we can click on (which we usually assign an icon to). When setting the Style property to DropDownButton, the ToolBarButton becomes “split” and effectively has two parts: the "icon" part and the "arrow" part, the implication being that you will also assign a ContextMenu to the DropDownMenu property.

So, assuming we've setup a toolbar button as described, what does it look like and what does it behave like on the PPC versus vanilla-CE device? (For the following discussion, if you don't have a device handy and wish to check my observations, you can use the emulators. The CE one with VS.NET 2003 is based on 4.1, the bug is only present on 4.2 - trust me!)

Appearance
- On PPCs, the line separating the arrow and icon parts is always visible. So the user (with their handy stylus) gets a hint that, if they click on the arrow part, something different will happen compared to if they tap on the icon part of the toolbar button.
- On vanilla windows CE 4.1/4.2 devices there is no line separating the two, ever! [point A].

Windows Behaviour (native)
- I could not find a native application running on a PPC that uses ToolBarButtons with an arrow (if you let me know of one I'll update this entry - it is irrelevant to my overall point)
- On WinCE 4.1/4.2 we can launch Windows Explorer. Notice that there is a ToolBarButton with an arrow ("Views" - just like on the desktop). The punch line is that tapping anywhere on that button (arrow part OR icon part) will show a menu; there is no separate click action [point B].

.NET Behaviour (managed)
- A managed app on PPC visually separates the icon part from the arrow part, as we established earlier; behaviourally they are also separate, i.e. tapping on the arrow part shows a menu, whereas tapping on the icon part performs a click action. In code you can trap the click action but not the arrow_tap (it will automatically put a menu up).
- A managed app on CE 4.2 behaves the same! [Hint: It shouldn't] On CE 4.1 the behaviour is correct i.e. different to the PPC (and same as the native Windows Explorer)

Conclusion
This is an area where the CF does not conform to the platform it runs on. My claim is that a CF app should not behave the same on PPC and CE devices in this area.
- The main reason it shouldn't is that, as per point A above, there is no visual distinction between the two areas (either fix the bug of the OS or fix the bug of the CF - preferably the latter).
- The second reason it shouldn't is because typically on non-PPC CE devices there is no stylus or mouse, so asking a user to tap within 9 pixels using their finger is a bit much.
- The third reason it shouldn't is because, as per point B above, even native apps don't treat the button as having two behaviours.
- Finally, why break the correct behaviour of CE 4.1?

Next time we'll explore a workaround.

No links here to some new CTP download or to some language feature getting dotslashed (I know it is the other way round :) although I could have linked to the 3 CLR videos

Earlier in the week I came across a writing that expresses a view which I fundamentally disagree with, but at the same time have to admit that the author is absolutely right! It may be long but I suggest you go read Sriram Krishnan entry (and then decide where you stand).

Soon we will be adding web-serving capability to our CE-based product so this entry was very welcome.

My introduction to .NET was at the annual VBUG conference in 2000. I have never been back to one (mainly cause I go to TechEds instead) but this year Peter Westwood was there. He has a nice write-up of the final day on his blog so go read it!

Maximizing .NET Performance

.NET Framework Tour from a Performance Perspective - 4stars

There are no other books on .NET Performance so, when this one fell in my hands, it put a smile on my face (sad, I know). When I got to the end, I was not disappointed. Around 250 well-written pages over 15 chapters and, as you'd expect, you can delve into it in random order, making it a good reference book. Even so, I read it cover to cover. The first two chapters lay the ground; the last chapter provides generic advice on troubleshooting and the 12 chapters in-between focus on specific .NET areas: a framework tour from a performance perspective. Naturally, a subject of this nature assumes the reader has some .NET experience and targets the Intermediate/Advanced level.

Don't expect material on GUI (Windows.Forms), Database (ADO.NET) and Web (ASP.NET); rather a discussion on elements that every application is built on (Type design/implementation, Strings/Text/RegEx, Collections, Language Specifics, GC & Object Lifetime, Exceptions, Security, Threading, IO/Serialisation, PInvoke, CLR). I challenge you to find a chapter that does not teach you at least one thing you were unaware of before. We have to sum it up with the great technical phrase: "It is all great stuff".

There are no axioms presented, and readers expecting a "cookbook" will be disappointed. Every claim is backed up with a reference to a testcase and even then, only after we have delved under the covers to see *why* something is slow or *how* a change makes something faster. By taking this approach, the reader should be able to repeat the investigation/tests for newer/other versions of the framework. So, having just mentioned how there is a cross-reference to specific testcases, I have hinted at what is one of the best contributions of this book: A .NET Benchmark Test Harness. This is described in the appendix of the book and the code/binaries can be obtained from the publisher's site.

Now how about something like this for the Compact Framework?

Reading technical books is something I have always enjoyed, including writing reviews about some of them. The very first book I reviewed was over 5 years ago (Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns) and the first .NET book I read was in 2000 (Presenting C#).

My recent focus was on .NET Compact Framework Books. I have read and reviewed all of them (let me know if I've missed any - although it's unlikely I'll be reading a book on the CF 1.0 now that the CF 2.0 Beta is out). If you are writing a CF 2.0 book let me know.

Some of my reviews are over at my Amazon page (.NET, UML, OO and COM being the dominant theme).

More and more magazines make their articles available online (and we already subscribe to quite a few at work), even more informative blogs become available with nice technical content and more Alpha/Beta software is made available earlier and to wider audiences. All of this means that my book intake has gone down (hasn't yours?). It is up to you (as a publisher/author) to change that by sending me prospective .NET books to read/evaluate :-)

Having said all that, I recently finished reading Maximizing .NET Performance (I won it at a competition). The review will also appear as my next blog post.

D.D.G. MOTH (Amazon Associate)

One of the first complaints .NET desktop developers have when targeting the CF v1.0 for the first time is "Debug.WriteLine doesn't work".

The fact is that with Smart Device projects the debug output does not come back to Visual Studio; rather it goes to the console on the target device. It is true that Debug/Console WriteLine statements do not appear when debugging on PocketPC devices/emulators, but this is not a CF issue; it is rather due to a lack of console on the PPC platform. Debugging a CF app on the CE emulator or a CE-based device results in the display of a console window on the target with the debug statements. Note that even on a CE device, if you build it without the console (cmd.exe) you will get no debug output (I should know, since I have accidentally run into that scenario when we ported from CE 4.1 to 4.2, but I digress).

So what can you do about it? There are a number of options and I will link to them in this entry, ready for the next time someone asks :-)

Add a console to the target, e.g. this one

Redirect the output to a file, e.g. like this

Send the output back to the dev machine, e.g. like that or that

Of course you could switch away from using System.Diagnostics directly and write your own logging framework. As you'd expect, this has been done before and there are a number of 3rd-party solutions, some of which may be too simple and others too complex for your project's liking. So here are some options:

MSFT offer the Enterprise Instrumentation Framework, but I doubt it supports the CF.

I have met references to log4net a few times, but I don't think it supports the CF it is under the Apache license.

Over at the useful openetcf there is a logging system, but I must admit not having played with it, and I don't know if it works on the desktop

For my own projects (CF and full Fx), I have been using a class I wrote years ago. Features include:
1. Just one file to include in your project. Only one class with static methods.
2. Use of the standard Debug class internally, so the output goes to VS console (desktop) or device's console (CF)
3. CSV formatted output (inserting additional info such as timestamp etc.)
4. Redirection of output to a HyperTerminal on the desktop, when running a debug OS on your CE target
5. Support of 3 severity levels (Info, Warning/Assert and Error). Auto detectable based on project configuration (e.g. DEBUG, TRACE)
6. Further configuration available via TraceSwitch (both platforms) and optionally via config file (desktop only)
7. Writing to a file (on both platforms, path and name computed internally also take into account COM Interop clients)
8. Rolling of the filename, thus preserving debug info between different runs of the application

Feel free to play with it.

If you are interested in the subject of tracing, you will love a new feature in Whidbey: Tracepoints. I was going to write about it, but many others have done so already [1,2,3]

UPDATE:
Visual Studio 2005 (and .NET Compact Framework v2.0) support Debug.WriteLine :-D

The December issue of the MSDN Magazine comes with a nice CF article, go read it:
Optimize Your Pocket PC Development with the .NET Compact Framework

Here is its outline:
-Essential Goodies and Our Test Bench
-Bad, Wicked Dialogs
-Chilling Out the Context Menu
-Designable Custom Controls
-Optimization
-Getting Resourceful
-Load Only What You Need; Chuck What You Don't
-Putting It All Together—the TabControlEx Class
-Adding Toolbar Buttons to TabControlEx
-Conclusion

Almost two years ago I was asking why VB adds extra IL lines in try catch situations compared to C#. I got an unsatisfactory answer. Now, someone that seems to agree with my sentiments blogs about it. Cool!

The Compact Framework does not support the AssemblyFileVersion attribute. Instead, whatever .NET version you give to your assembly (via AssemblyVersion) will also be its Win32 file version. Neil shows you how to give an alternate Win32 file version to your CF assemblies without resorting to command line compile. Go read it and let me know when you are back!

OK, so although I am an advocate of everybody understanding both languages, I have done the VB version for you here. Note that this will only work if you have not chosen to use the Root namespace in your VB project properties (which as I've said before is a bad habit anyway).



While on the subject of versions, it is worth pointing out that the Product Version of your file can be set with the AssemblyInformationalVersion.

You are wrong if you think I'll link to the new browser launch (ieview is the best thing it has going for it) OR about the new MSFT game (when I get time to play a game I go here) OR about the poor devs at that game company (naturally I sympathise) OR about the flash CV of the Frenchman OR about YA search engine and I am definitely not telling you what file extension I am! [if none of these references make sense to you, stay in and read more blogs:-]

Instead, go read why Thread.Abort is evil (good thing the CF doesn't support it then so I didn't use it here :-)