Hi there,
I use ST emWin on STM32F4xx, have some issue with window callback.
I implemented some file I/O operations, and this IOfunction called from button callback
IOfunction will call some dialogs for user confirmation, and when conf dialog closed, WM start button callback (if touch event) again and app crashes.
Expected: button callback -> IOfunc -> conf dialog -> ret to IOfunc -> ret to but callback
Reality: button callback -> IOfunc -> conf dialog -> (WM repainting, and if but hit again) -> button callback -> IOfunc (when IOfunc is already in process)
Is there any legal/common approach to avoid such double/triple recalls of widgets callbacks?
May I launch blocking dialogs from button callback ?
I tried to play with modal windows, but again, when series of modal windows called one from another, whole stack of windows lose their modal property when topmost window closed.
Your advice very appreciated
Serge
I use ST emWin on STM32F4xx, have some issue with window callback.
I implemented some file I/O operations, and this IOfunction called from button callback
IOfunction will call some dialogs for user confirmation, and when conf dialog closed, WM start button callback (if touch event) again and app crashes.
Expected: button callback -> IOfunc -> conf dialog -> ret to IOfunc -> ret to but callback
Reality: button callback -> IOfunc -> conf dialog -> (WM repainting, and if but hit again) -> button callback -> IOfunc (when IOfunc is already in process)
Is there any legal/common approach to avoid such double/triple recalls of widgets callbacks?
May I launch blocking dialogs from button callback ?
I tried to play with modal windows, but again, when series of modal windows called one from another, whole stack of windows lose their modal property when topmost window closed.
Your advice very appreciated
Serge