All the event processing (input, paint events etc) are being driver by CGapiApplication::processNextFrame() ( my app is pretty much synchronized by this function.)
I also implemented something akin to windows modal dialog.
Something that you can call with :
MyDialog mdlg(....);
int result=mdlg.exec();
The actuall exec call is a blocking call , meaning it should not return until the dialog is dismissed.
I implemented this using my own mini-event loop which looks like:
- Code: Select all
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23int WR_ModalDialog::exec()
{
// Some prolog code here ...
while(iActive)
{
// Doing my windowing processing here
if (GDERR_FRAMETIMEOVERFLOW == wrApp->m_timer.WaitForNextFrame())
{
Sleep(1);
}
wrApp->display()->Flip();
}
// Some other code here ...
return iRetValue;
}23 lines; 4 keywds; 1 nums; 34 ops; 0 strs; 3 coms Syntactic Coloring v0.4 - Dan East
This is basically copy of CGapiApplication internal thread function.
Again, since all the processing in my little toolkit originates from CGapiApplication::processNextFrame() call, it should in effect end up as sort of inner
while() loop inside of CGapiApplication::ThreadFunc(LPVOID pParam) function,
I am just wondering if this is the correct way of doing this kind of processing and if there is something else CGAPi is doing behind my back I should know about ?
Thanks
- Code: Select all
- 0 lines; 0 keywds; 0 nums; 0 ops; 0 strs; 0 coms Syntactic Coloring v0.4 - Dan East
