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.