PocketMatrix

Any tips on how I can set up PF to run in a subwindow.

I'm working on a GUI for the H/PC with an 800x600 display and what I want is a regular windows program (NOT MFC) to act as the mainframe for the GUI, and then when selected from the menu, display and run a PF visualisation in a subwindow.

I've managed to arrange this behaviour, but it only works ONCE. After I've closed the PF window (by calling PostQuitMessage(0) in StylusDown()) I can't start it again. All it draws is the frame with nothing in it (and no callbacks, så I can't close it again neither).

Any hints on what I'm doing wrong here? The code is at if that would help. It's based on the "Hello World" WCE Application skeleton. I'm kinda new to windows programming so I'm hoping it's just something I've missed. The main window is not ATL based, could this be it. Changing it (from regular windows style) to ATL ain't that hard (I hope) but it would be nice if I didn't have to change any code since the rest of the stuff is working just fine and it's easy to expand.

I register the PF/ATL window with "_Module.Init( 0, hInstance );" after I've registered the main window. And I start PF by invoking PFClass.Run() in the WndProc Callback function (when selecting the proper menu item)

It seems like PF is not completely and correctly exited/destroyed and that's why it refuses to start up a second time (just as if you try to run two PF windows at the same time).

Also, how do you get the PF to display a "Close this window" icon in the upper right corner (as one gets with all the other windows and dialogs you create).

Obviously you can, since not many regular GUI applications are multi threaded.

But the problem is that you want to call GameLoop() over and over. If you create two windows, you have two game loops to call. Without building some sort of global queue of window objects, calling each after another, the simplest way is to use a separate thread for each window.

As you said, the message pump (or whatever it's called) will take care of all the window messages and dispatch them to their respective window. BUT this is provided that the main thread (or GUI thread as I would like to call it) doesn't get stuck somewhere.

For instance, say you get an event from a menu or a button and you want to create a new object/window or call a function in a given object as a result. If that object (or function) has an infinite while loop (or for some other reason doesn't return to the event handler function) it will lock the GUI thread and you'll stop processing events.

So, this is why you need one thread for each window, to keep the GUI thread free.

Had the window been a standard ATL window which is only updated/redrawn when it recieves a WM_PAINT event, then you only need a single thread because it will never get stuck (unless you call an function that doesn't return to the event handler ofcourse)

Come to think of it, you should be able to rewrite PF using the WM_TIMER event to call GameLoop with a given interval, and then use Suspend() and Resume() to stop and start the timer. This will work with a single thread. Provided you only update the window that currently has the focus, this approach will behave exactly as the multiple threaded one if you set the timer correctly. If you want several windows to update its content simultaniously, then perhaps the WM_TIMER approach will work even better since each window will wait for the other to return from the WM_TIMER event handler function. The only way to get this with threads is to define them as uninteruptable (you can do this in WinCE but not on Win32) and hence you should avoid updating more than one window at a time (it will produce flicker or not fully updated windows)

Hmm.. seems the WM_TIMER approach would be better. I don't know why I didn't use it myself. Probably because I didn't knew it excisted and I knew I would use threads for some network stuff anyways. I guess the only hard part is to figure out a good timer interval. On WinCE the timer resolution is 1 ms/tick, but on 2000/XP it is 10 ms and on ME/98 it is 55 ms giving a maximum (theoretical) framerate of approx 18 which is way too low. Setting the interval to 1 (tick) will guarantee the fastest performance, and the windows will interleave in random order (but never twice in a row).

Anyways.. that's something to think about.

Looking at timers some more and I found out that on the PC there is something called multimedia timers and high-resolution timers which one can use instead of the standard timer to get a higher resolution. I recon a timer of 1 ms should suffice (generating a theoretical maximum framerate of 1000FPS for a single window).