WM_TOUCH_CHILD press always zero

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • WM_TOUCH_CHILD press always zero

      Hi everybody,

      I'm working on a user interface base on emWin functionalities and everything is working in the right way. Now, I'm looking to optimize touch, but while debugging I've faced a strange behaviour to me.
      I've Window Manager enabled, a simple window with 4 buttons and a custom callback assigned to this window and I would like to better understand the "flow of messages", such as WM_TOUCH and WM_TOUCH_CHILD.
      Putting one breakpoint on the WM_TOUCH_CHILD case and on on the WM_NOTIFICATION_CLICKED, when I touch a button I get the program stopping at WM_TOUCH_CHILD and then in WM_NOTIFICATION_CLICKED, as expected. The strange thing is the "Pressed" value of the GUI_PID_STATE field to which "p" pointer of the message points to, is always 0.
      This should not have sense, because a WM_NOTIFICATION_CLICKED is triggered by a pressure, or am I missing something?

      Also, the other strange thing is X coordinates is out of the displayed range: I've got a 320x240 pixels display, and often X value reaches 500 and more. Why this?

      Thanks
    • Hi,

      This is kinda tricky. If you receive the message WM_TOUCH_CHILD, the pointer of the message (pMsg->Data.p) points to the message (WM_MESSAGE) of the child window.

      This means that if you want the GUI_PID_STATE you have to cast twice. First to another WM_MESSAGE and then to GUI_PID_STATE.

      Like this (where pState is a GUI_PID_STATE pointer):

      C Source Code

      1. pState = (GUI_PID_STATE *)((WM_MESSAGE *)pMsg->Data.p)->Data.p;
      This is not well described in the manual and we will improve that.

      Regards,
      Sven
    • Hi,

      Hard to say, occurs the release within the button area?

      If you move the input out of the button area while keeping it pressed the button won't get a release message. It gets the release only if it happens within its area.

      With little buttons on a screen with an imprecise touch this can happen quite quickly.

      Give it a try and test it with a big button.
      Does it always get a release?

      If it doesn't, check the touch implementation. It is important to pass the unpressed state (Pressed member of GUI_PID_STATE is 0) with the same coordinates as the last pressed event to emWin. Otherwise the unpress event occurs anywhere else on the screen and the button never gets the release.

      Regards,
      Sven
    • Hi Sven,

      that the point I came out me too. We've a resistive 320x240 touch screen display, with buttons 80 pixels wide and 45 pixels height: not so big, but quite usable. Unfortunately, display is not a the same level of the case in which it is placed, but there is a little thickness that does not make so friendly to use buttons on the borders.

      We've noticed that pressing the finger and, while keeping pressed, moving across the screen, a WM_NOTIFICATION_CLICKED message is emitted every time the finger is inside its area. This is a behaviour we don't would like, so we've tried to set-up a simple "high level filter": once a WM_NOTIFICATION_CLICKED generated by a button is triggered, a flag is setted and it's cleared only when the touch is released. In our point of view, touch release happens with WM_NOTIFICATION_RELEASE, WM_TOUCH_CHILD with Pressed variable 0 or WM_TOUCH with Pressed variable to 0.

      We achieved what we'd like, so "drag" on buttons trigger WM_NOTIFICATION_CLICKED of the first button pressed only, but sometimes the flag is not cleared: this mean, if everything is implemented correctly, that no WM_NOTIFICATION_RELEASE, WM_TOUCH_CHILD or WM_TOUCH are detected.

      Adding also WM_PID_STATE_CHANGED in our window callback function, and evaluating when Pressed state is 0, does not change the behaviour. "Missing" of some release events seem to persist.

      Thanks
      Andrea