Typical model for a dialog/screen based application

Hi folks,
I'm trying to construct an app that will use several screens with buttons, text fields and so on. I've used the GUI Builder to construct skeletons for the screens and it includes a procedure that calls GUI_CreateDialogBox() to display the dialog. I've put this into the HelloWorld demo and added a call to GUI_Exec1() in my main loop. (No OS, just a polling loop.) With a little tweaking of the touch driver I get touch events for the windows (using GUI_TOUCH_StoreStateEx() to pass touch events along to STemWin.) My main procedure also calls __CRC_CLK_ENABLE() and GUI_Init() before looping.

Code switches to another screen by calling GUI_EndDialog() for the current dialog followed by the create procedure for the next dialog. At this point everything seems to be working. It can even switch to a third screen by calling it's create procedure. When it goes back to the initial screen, that comes up but the app no longer gets touch events. The driver seems to stop receiving touch events leading me to suspect that some kind of memory overwrite has corrupted some data structure the touch driver depends on.

My questions are:

1) Is this a typical model for switching between several screens? I tried to find example code that does this but the examples seem to either be HelloWorld which does practically nothing and various demos coded more to demonstrate lots of emWin capabilities ()and thus rather complex.) Pointers to a simple demo that moves between several simple screens would be really welcome!

2) Are there critical calls I have left out that are required for this to work? For example, I tried not calling GUI_EndDialog() and reusing the handle with GUI_ExecCreatedDialog() and that got a hard fault without returning.


I've studied the manual with hope that I would find a helpful clue but did not. If it exists and I have just not found it, feel free to suggest that I study it more (and hopefully point to a particular section.)

Thanks!

Thank you both for the replies.

GUI_ExecCreatedDialog() is definitely not for this application which operates via main loop (no RTOS.)

I think I smashed it. The procedure I'm using:

1. On entry to the main loop (and following all initialization) call GUI_CreateDialogBox() using arguments produced by the GUI builder.
2. Within the _cbDialog(WM_MESSAGE * pMsg) procedure (and with the WM_NOTIFICATION_RELEASED message for the button that should switch screens) call GUI_EndDialog() with the handle returned by the preceding GUI_CreateDialogBox(). Set a flag to indicate the next screen to load.
3. In the main() loop, call GUI_CreateDialogBox() for the next dialog to display.

It also seems to work to call GUI_CreateDialogBox() immediately following GUI_EndDialog() in the button handler. Originally that did not work until I had the brilliant idea to go into linker settings and increase stack and help. (smacks forehead.)


It seems a little costly to destroy and create the dialog each time, but I do not see a way to reuse a dialog that will work with a polling loop.


Further comments on this usage of the APIs is welcome!


thanks,
hank