I am using emWin with FreeRTOS.
I have a GUI task that handles the emWin dialogs and I am looking for the correct way to handle the touch interface.
A few of the dialog controls trigger pop-up confirmation dialogs which use GUI_ExecDialogBox and GUI_EndDialog to obtain the confirmation or cancellation input.
Currently, my touch driver places the x,y coordinates into a message queue to be received by the GUI Task. Since the confirmation dialogs execute to completion my touch input message queue does not get handled and the pop-ups can not be dismissed.
I am wondering if I have over-complicated the situation and should just call GUI_TOUCH_StoreState directly from my driver rather than use the message queue.
Is GUI_TOUCH_StoreState save to be called in this manner or will it introduce concurrency issues?
Does GUI_TOUCH_StoreState call GUI_Lock when emWin is compiled with GUI_OS defined as 1?
Thanks
I have a GUI task that handles the emWin dialogs and I am looking for the correct way to handle the touch interface.
A few of the dialog controls trigger pop-up confirmation dialogs which use GUI_ExecDialogBox and GUI_EndDialog to obtain the confirmation or cancellation input.
Currently, my touch driver places the x,y coordinates into a message queue to be received by the GUI Task. Since the confirmation dialogs execute to completion my touch input message queue does not get handled and the pop-ups can not be dismissed.
I am wondering if I have over-complicated the situation and should just call GUI_TOUCH_StoreState directly from my driver rather than use the message queue.
Is GUI_TOUCH_StoreState save to be called in this manner or will it introduce concurrency issues?
Does GUI_TOUCH_StoreState call GUI_Lock when emWin is compiled with GUI_OS defined as 1?
Thanks