4

.NET CF WinForms app runs on Windows CE5 and CE7 devices, with touchscreen.
We hook up to MouseUp event rather than Click in our Button implementation (because of apparent problems with touchscreen sensitivity).

We also hook up a Windows Message filter on application message queue, and filter out MouseDown and/or MouseUp messages based on certain conditions (e.g. screen backlight is off). Normally messages are let through.
Another thing to note - all screens in the application are implemented as controls, and kept in memory forever, just sent to the background. We use OpenNETCF Button2 and Application2.

Now there's a very strange problem, where particular button event handlers get "stuck": event is fired when button is pressed, as expected, but then again after a random time interval - sometimes 20-30 minutes after!

There would be screen interaction in the meanwhile, user presses other buttons, the original screen control and the button become invisible, and then suddenly - typically on next screen touch - the same MouseUp handler for this button is fired again, and then keeps firing.

It also seems to happen with different buttons in the same, certain position on the screen, not each and every button.

The primary question here is - how on earth can an event (MouseUp message for this particular control?) get stored somewhere, and then activated/sent again some time after?

Control is invisible by the time, so it can't be physical touch, presumably.

Behzad
  • 3,502
  • 4
  • 36
  • 63
enkod
  • 91
  • 2
  • 8
  • Since you're already hooked on the message queue, any chance to log its activity for the `WM_LBUTTONUP` message and the window handle it was sent to? Be sure to log the window handle of the button(s) that show this behavior. Perhaps with that information you can determine whether the OS is to blame or .NET code. – C.Evenhuis May 27 '15 at 13:35
  • There might very well be a defect on/in the touchscreen. Resistive TS are critical to damage in the seperation layer, for humidity from the sides and temperature (or a combination thereof). That might very well be affected by a touch and occur after some time randomly (have that on a TomTom for instance). For capacitive TS there are also potential defects. If possible replace the TS (or TS/display module). – too honest for this site May 27 '15 at 13:42
  • @C.Evenhuis - was considering this option; will make logs very noisy though. But may have to resort to it, if nothing else. – enkod May 27 '15 at 13:54
  • @Olaf - this would be an obvious answer, but the button is invisible at the time event is fired again. – enkod May 27 '15 at 13:56
  • @Olaf - if it was a physical defect then it would not be able to trigger an event on a button that is no longer present. Similarly if it was at the touchscreen driver level then this would be registering repeated events at a location rather than on a now-removed button. The first place I'd be looking would be event propagation when a button has been removed, in case there's an issue there. – David Burton May 28 '15 at 15:10
  • 1
    The windows message queue, which also handles Mouse_Down events, is a sequentiell queue. The messages are delivered to a handle (or window) and will be removed, if the message queue handler let's the OS know that it handled the message. If a messsage handler returns FALSE for a processed message, it is not removed from the queue and should be processed by the parent window (and on, bubbling up in the hirachy). This is a very simplified description! But either your code does not handle the messages correctly or you have a defective touch display (or the device/driver is defecivv). Use logging! – josef May 28 '15 at 16:42
  • @josef we use OpenNETCF Application2. Simplified code inside Pump() method: ` if (NativeMethods.GetMessage(out msg, IntPtr.Zero, 0, 0)) { process = //ask user filter whether to process message if (process) { NativeMethods.TranslateMessage(out msg); NativeMethods.DispatchMessage(ref msg); } return true; } return false; ` – enkod May 28 '15 at 17:20

0 Answers0