APPWizard not sending APPW_NOTIFICATION_CREATE signal

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

    • APPWizard not sending APPW_NOTIFICATION_CREATE signal

      I'm having trouble using the interaction and custom code integration with appwizard. I would like to set the text in a textbox on startup to a custom string (ie. a serial number, only present at runtime).

      for this task, I was thinking to add a text box on the screen, add a APPW_NOTIFICATION_CREATE signal sent by the parent screen. there I can have either two options: NULL receiver to execute the user defined code, or the SN text box as a receiver with SET_TEXT as a job, but in neither of those case, the corresponding slot routine is called. the only way to call it is to add a call to APPW_SendNotification in the screen callback in case of WM_INIT_DIALOG, but i dont think that's how it was intended?

      Maybe you have some ideas on wherre is my misunderstanding. other interactions (ie. button click to swap screen) works fine, and i can update the text on button click aswell.

      I also cannot find how to set the text of *this* textbox from code, since the EmWin functions seems to be one layer of abstraction below AppWisard exec

      Best regards, i hope you can help me,

      Alexis Marquet
    • Hi,

      you do not need interactions to do this. You can set a text to be displayed initially by a TEXT object by setting the "Set text" property of the object (shown on the right when the object is selected).

      Before adding texts, you have to define the name of the language first. When this is done, add a text and edit it by double clicking the "-". Then, you can click the text and click the "Select" button.

      Best regards,

    • Yes, but that is not possible to set a text that is not know when building with appwizard, such as a serial number. my problem is trying to set the text at runtime, not while designing with appwizard, if that is more clear. How can I set a text that is not in the "text" resources from appwizard, and set it when the UI is loaded/created?

      Best regards,

      Alexis Marquet
    • Hi,

      I did this adding an interaction like this: ID_SCREEN_0 -> INITDIALOG -> SETTEXT -> ID_TEXT_00

      Then, I modified the slot routine (in ID_SCREEN_00_Slots.c) to do this:

      C Source Code

      1. /*********************************************************************
      2. *
      4. */
      6. WM_HWIN hText;
      7. hText = WM_GetDialogItem(hScreen, ID_TEXT_00);
      8. TEXT_SetText(hText, "12345");
      9. GUI_USE_PARA(pAction);
      10. GUI_USE_PARA(pMsg);
      11. GUI_USE_PARA(pResult);
      12. }
      Display All
      Note that this currently only works if in AppWizard the "Set text" property is left empty.

      Best regards,

    • I tried doing the same thing as you with everything else removed from the appwizard project:

      C Source Code

      2. WM_HWIN hText;
      3. hText = WM_GetDialogItem(hScreen, ID_TEXT_00);
      4. TEXT_SetText(hText, "12345");
      5. GUI_USE_PARA(pAction);
      6. GUI_USE_PARA(pMsg);
      7. GUI_USE_PARA(pResult);
      8. }

      But while that works in the simulation (with the text set in "set interaction parameter" to check), it does not work on target. the callback shown above is never called. Would it be possible to check against your _aAction in ID_SCREEN_00.c?

      C Source Code

      1. static const APPW_ACTION_ITEM _aAction[] = {
      3. { ARG_V(ID_TEXT_1),
      4. }, 0,
      5. },
      6. };

      Hope we can narrow it down, tell me if you need more details

      Best regards,

      Alexis Marquet
    • [Solved] APPWizard not sending APPW_NOTIFICATION_CREATE signal

      Allright i found what was causing the issue. I changed the headers from the ones distributed with appwizard and it fixed the problem. I thinkthe ones i had were a previous version, so I think some of the values from define/enums were different from the ones in the compiled library, because some jobs were working, some not.

      Thanks for your support, it helped me to narrow it down.

      best regards,

      Alexis Marquet