SP3 Beta: ListView.Click still broken

  • Thread starter Thread starter Mike Dimmick
  • Start date Start date
M

Mike Dimmick

Thanks for posting the .NET CF 1.0 SP3 Beta. For anyone
reading who hasn't seen this, instructions for grabbing
the beta are at
http://blogs.msdn.com/onoj/articles/178293.aspx.

The ListView.Click event (inherited from Control) doesn't
fire. It doesn't fire in SP2, and I'm not sure it's
*ever* worked. The workaround, using
SelectedIndexChanged, both interferes with keyboard/d-pad
interaction, and fires on mouse down, not mouse up. This
can cause problems if a new form is shown in the
SelectedIndexChanged handler; since the mouse appears to
be captured, the new form loads, but when the stylus is
released, the original form is brought back to the top.

The Click event is a fundamental part of interaction with
almost any control, especially with a device where the
primary and practically only means of interaction is via
the stylus.

The fact that the mouse is captured by the framework is
surprising to this seasoned Windows developer, but is
consistent with the desktop behaviour.

While on this subject, I don't expect to get the 'tap-and-
hold' animation on the Pocket PC unless I've set the
ContextMenu property. It's disconcerting.
 
OK, I've now downloaded the VS2005 beta and guess what, now I get a compiler warning:

warning VSD101: Members not supported by the Device platform should not be called: System.Windows.Forms.ListView.add_Click is not a supported method in this platform

(this was using a Pocket PC 2003 Windows Application project)

I've now found the ItemActivate event and the accompanying Activation property, which is obviously (now!) the correct solution. I seem to be one of very few people who've found this. This is a serious deviation from the desktop and the documentation, and needs to be explicitly called out, with a _specific_ warning suggesting the alternative event. Or just fix it so that Click works.
 
Back
Top