Strange behaviour of WM_GetId() after using WM_SetCallback()

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

    • Strange behaviour of WM_GetId() after using WM_SetCallback()


      I am using the latest (5.48) emWin evaluation version for prototyping our project by simulating it on PC and have a very strange problem using BUTTON widget.
      I create some buttons with BUTTON_CreateUser(), because I need to exchange data with it. For detecting the usage of the button I use WM_GetId() with the handle found from WM_GetFocusedWindow() and everything works, the right Id of the button having focus at the moment is properly detected.
      But now I want to customize the style of the button and use the callback routine. And it doesn't work anymore. After any usage of WM_SetCallback for the buttons the Id of the focused button is not more detectable. I get the right handle of the button using WM_GetFocusedWindow(), but WM_GetId() for the received handle returns only zero (0). Then I comment the line with WM_SetCallback() out it works again how it should be.
      I have checked everything in the callback routine, it seems to be ok. I have put WM_GetId() at the top of the callback routine, but it doesn't really help, the result Id is always 0, so I'm sure the Id is not destroyed within the callback.
      Is it possible, that the usage of callback routine destroys the Id of the widget? I have used older versions of emWin (5.28 for example) before and have never seen such a problem.

      Thank you in advance and waiting for your reply.

      The post was edited 1 time, last by Polarisru ().

    • Hello,
      Maybe WM_GetId using WM_GET_ID message, in manual 18.6.1 said WM_GET_ID Sent to a window to request the Id of the window.

      When you use WM_SetCallback(), must handle WM_GET_ID message or use default handle.
    • in manual 18.2.1: void Callback(WM_MESSAGE * pMsg) The action performed by the callback routine depends on the type of message it
      receives. The prototype above is usually followed by a switch statement, which
      defines different behaviors for different messages using one or more case statements
      (typically at least WM_PAINT).

      It is said: AT LEAST WM_PAINT
    • Hi,

      @Polarisru, try using the BUTTON default callback, BUTTON_Callback(pMsg). This will make sure that the default behavior of the button will be implemented.

      This will also fix the issue regarding IDs. A normal WM-window doesn't implement ID managament. So, if you call WM_DefaultProc() no ID will be return when calling WM_GetId(). But if you use BUTTON_Callback() it calls the internal button callback function and return the ID set for the specific button.

      We already noticed that the describion of the callback function in the manual is not clear enough and we will add further notes with the next release.